-
Notifications
You must be signed in to change notification settings - Fork 80
Google Summer of Code 2015
SciRuby
Ruby Science Foundation
We believe that the time for a Ruby science and visualization package has come. Sometimes when a solution of sugar and water becomes super-saturated, from it precipitates a pure, delicious, and diabetes-inducing crystal of sweetness, induced by no more than the tap of a finger. So it is today with numeric and visualization libraries for Ruby.
The SciRuby project is oriented towards providing computational research infrastructure. Infrastructure was the single common area of need identified by scientists, researchers, and engineers in discussions at the GSoC 2013 mentor summit. SciRuby consists of a fairly large number of gems, including statsample, statsample-glm, statsample-timeseries, distribution, minimization, integration, rubyvis, plotrb, Nyaplot, MDArray, Publisci, Ruby-Band, and NMatrix.
The last of these has been awarded grants by the Ruby Association (which develops the Ruby language) as well as Brighter Planet, and has a goal of supplying Ruby with a robust, versatile linear algebra library with support for both dense and sparse matrices. Statsample and its related packages (e.g., distribution) aim to provide the Ruby language with statistical analysis packages.
A major portion of our gems have been written by GSoC students — including Nyaplot, plotrb, PubliSci, Ruby-Band, statsample-timeseries, and statsample-glm. Others, like minimization and integration, have been overhauled over the course of Summer of Code projects.
Working on SciRuby is a chance to get involved at the ground floor on a project which is viewed as critical by many Rubyists, including Ruby's creator, Matz. Further, since we are a science-related project, we expect that successful student projects could lead to publications. Better yet, you might get to see your code go into orbit, or used to save lives in biomedical research.
science, ruby, engineering, data visualization, scientific computing, c, c++, java, space, biology, chemistry, physics, graph theory, statistics, bioinformatics
New and simplified BSD
https://github.com/SciRuby/sciruby/wiki/Google-Summer-of-Code-2015-Ideas
https://groups.google.com/forum/#!forum/sciruby-dev
https://plus.google.com/+Sciruby
If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year.
SciRuby has participated for the last two years in Google Summer of Code; both years we had four students, and none have failed.
Our key challenge has been finding individuals from underrepresented groups (particularly women and gender nonconforming) to participate. Our goal last year was to increase underrepresented student participation by recruiting female mentors to act as role models — and while we found a number of female scientists and engineers who agreed to serve as mentors, none of them followed through once student applications started. We had one female student this last year (who represented our organization at the Mentor Summit), but our attempts to facilitate participation of members of underrepresented groups in our project have thus far been less effective than we would have liked.
One area where we have had success — and which we plan to continue — is in discouraging male contributors from creating a hostile environment. One particularly effective strategy was the inclusion of a bonus question, "One aim of the SciRuby Project is to increase diversity in open source science software development. How do we get more women interested in open source software development and science?" in our student application. (We have refined this question for the present year to be more inclusive of other gender identities.)
The responses to this question were diverse. A very small number (1 or 2) made sarcastic remarks; and we communicated to these applicants that these remarks were inappropriate, and explained why. These interactions created opportunities for dialogue. A number of applicants provided insightful responses — and at least two of these applicants were ultimately accepted for our project.
The question served both as a way of weeding out those who would unapologetically create a hostile atmosphere for other students and as a strategy for evaluating students' ability to answer difficult questions (often in a second language). (Incidentally, we found that the non-native English speakers performed just as well on this question as the native English speakers.)
While we have no miracle approach for improving our outcomes with underrepresented groups, we plan to — at the very least — continue to ask questions which help us to gauge the inclusiveness of those we welcome into our community. We must be proactive — not merely reactive — in creating an environment which is inclusive to everyone.
Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating?
Our organization consists mostly of working scientists and engineers, who — as with nearly anyone who contributes to open source software — are often more focused on their own research projects' short-term needs than on contributing to scientific computing infrastructure. Scientists tend to write one-off code for their research — code which will never, or can never, be used for any other projects. SciRuby's existence facilitates contributions to the common infrastructure by those who have the interest; as with any community, it creates opportunities for collaborations.
Google Summer of Code acts as a catalyst for both student and non-student contributors. By seeking out "sometimes" contributors and convincing them to commit to mentoring, we transform our sometimes contributors into regular contributors. Most mentors stick around between summers. Interestingly, some of our most promising applicants (at least, those who appear likely to apply) for this summer appear to be students who we were not able to accept in the past.
How many potential mentors do you have for this year's program? What criteria did you use to select them?
We have at least six mentors for this year's program, with five of them prepared to be primary mentors. Our strategy for selecting mentors is simply to ask them personally — either with emails to our Google Group or by inquiring individually — and this has proved surprisingly effective. We have never left a student without a mentor, and we haven't had any problematic mentors (mentors who totally dropped the ball).
So far, disappearing students has not been a problem for our organization. We have had some cases where there was friction between students and mentors, and have worked quickly (and successfully) to limit communication between those. Another problem has been that some students have failed to meet our requirements of weekly blog entries. In general, we've found that rather than having a short checklist of requirements where every item must be met, it is beneficial to expect students to meet most of a slightly longer checklist of requirements (coding, of course, is always an absolute requirement). Students may thus work independently and don't feel overly controlled.
The other problem we've had is with students who have said, incorrectly, that they don't have other commitments during the GSoC period. We have handled these on a case-by-case basis, but our plan for this year is to ask more specific questions about other time commitments on the application. Instead of writing a general query, "Do you have any other commitments this summer?" we might pose specific questions, such as, "How many classes are you taking?" or "Do you have family vacation planned?" This reformulation enables us to avoid potentially difficult situations and ensure that the playing field is totally level for our applicants. More importantly, it keeps us from having to make difficult decisions about failing students who may have misunderstood the Google Summer of Code rules due to language barrier issues; it's easier to simply not accept a student who doesn't meet requirements than to fail one once accepted.
Our plan has always been to ensure that we have more than one mentor lined up for each project. We expect our mentors to provide a minimum level of investment — such as providing a write-up an idea that individual can mentor on our ideas page — and those who do not provide that investment are not assigned as primary mentors for students. (They may participate in backup mentoring roles.) We would rather accept fewer students than assign students to absentee mentors, and we have given some slots away for both of the last two years. So far, this strategy has proved successful, and we have never lost a primary mentor.
What steps will you take to encourage students to interact with your project's community before and during the program?
Included on our student requirement checklist are (1) Google Group participation, (2) blogging, and (3) IRC participation. This year we will require students to join the Google Group, and ask them to blog every week; but if they do not, we will accept vocal and thoughtful participation in the Google Group and IRC channel as alternatives.
In our first GSoC year, it was impractical for us to expect applicants to have contributed to SciRuby before. This year, we will require prior contributions — at least one pull request containing code, with documentation pull requests as bonuses. We provide a number of simple issues in several of our trackers, rated by difficulty level, which students may use as starting points for contributions. Greater consideration will be given to those students who participated consistently for many months over those who show up closer to the application period, but our primary goal is to gauge whether students can sit down and crank out code.
We also encourage potential applicants to participate in Google Group communications rather than emailing mentors privately. The goal is to eliminate appearances of favoritism and to allow students to collaborate with one another on their applications. Accepted students have often gotten some of their best ideas from discussions that have involved other applicants. Students who are unwilling to collaborate are generally not seen as a good fit for our community.
What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?
Clearly, one of the hardest parts of running a volunteer-based project is ensuring continued participation. It is particularly difficult — psychologically speaking — to enable students to find intrinsic motivations to participate once they have been provided with an extrinsic motivation (money).
As such, we never treat the money as the carrot, nor the withholding of money as the stick; the reward is the experience. If students enjoy their time with us, they are likely to come back in the future and provide contributions — or they participate in other projects. If they have negative experiences, we may never see them again. Avoiding misunderstandings on the application (such as with students who have other time commitments) is one way to avoid creating unpleasant experiences.
This is not to say that we are not prepared to fail students. Our approach is to treat the potential of failure as the stick and leave the money out of any discussions.