-
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; each year we have 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 approach last year was to increase underrepresented student participation by providing role models in the form of female mentors — and while we found a number of female scientists and engineers who agreed to serve as mentors, none of them stuck around for the whole summer. We had one female student this last year, who represented our organization at the Mentor Summit, but our general approach for encouraging members of underrepresented groups to participate in our project have proved ineffective.
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. (This year, we plan to refine the question 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. A number of applicants provided insightful responses — and at least two of these were 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.
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, who are frequently more focused on their own research 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. We don't expect that every community member will contribute code, but we like to provide an outlet for those who want to.
Google Summer of Code acts as a catalyst for both student and non-student contributors. By seeking out occasional contributors and convincing them to commit to mentoring students, we transform our occasional contributors into regular contributors. Most mentors stick around between summers. Interestingly, some of our most promising (likely) applicants 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 four mentors for this year's program. Our strategy for selecting mentors is simply to ask — 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). As previously mentioned, we have had difficulties in retaining mentors who were not male; however, we believe this retention problem is the result of asking female scientists who are either not really programmers at all or not Ruby programmers.
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 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 time commitments on the application. Instead of writing, "Do you have other commitments?" we might pose it 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.
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 of a couple of ideas on our ideas page — and those who do not provide that investment are not assigned students. 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 mid-summer.
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. Greater consideration will be given to students who participated consistently for many months over those who show up closer to the application period.
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 other discussions that have involved other applicants. Students who are unwilling to collaborate with others 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?
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.
Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application?
?