Google Summer of Code 2016 Application
SciRuby
Ruby Science Foundation
SciRuby is oriented towards providing science and visualization infrastructure for the Ruby Programming Language. We develop and maintain several libraries for this purpose.
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. 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, daru, and NMatrix.
NMatrix has been awarded grants by the Ruby Association in 2012 and 2015, 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 aim to provide Ruby with statistical analysis packages, while daru, nyaplot and gnuplotrb take care of data analysis and visualization. Nyaplot was also awarded the Ruby Association Grant in 2014.
A major portion of our gems have been written by GSoC students — including Nyaplot, daru, plotrb, PubliSci, Ruby-Band, statsample-timeseries, and statsample-glm. Others, like minimization, integration and nmatrix, 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, students might get to see their code go into orbit, or used to save lives in biomedical research.
ruby, jruby, c programming, c++
visualizations, data, math, science, space
New and simplified BSD
https://github.com/SciRuby/sciruby/wiki/Google-Summer-of-Code-2016-Ideas
https://groups.google.com/forum/#!forum/sciruby-dev
https://plus.google.com/+Sciruby
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 project. 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 and students stick around between summers. Interestingly, many of our potential mentors this year, including the GSOC admin, were students with SciRuby last summer.
6-10
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 for 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 every year we participated. So far, this strategy has proved successful, and we have never lost a primary mentor.
It is noteworthy that most of our mentors this year have either mentored with us previously, or have been deeply involved with the projects that they will now be mentoring. Atleast four of this year's mentors are previous GSOC students who have now chosen to mentor and enhance the projects they had started previously.
Incomplete projects have never been a problem for us. We have had some cases where there was friction between students and mentors, and have worked successfully to resolve them. In general, we've found that rather than having a short checklist where every item must be met, it is beneficial to expect students to meet most of a slightly longer checklist (coding is always a must). Students may thus work independently and don't feel over-managed.
Another problem is with students who incorrectly say they don't have other commitments during GSoC. Instead of general queries about other commitments, we pose specific questions (goo.gl/qw70d7) about summer classes, vacations or internships. Asking these questions avoids difficult situations and ensures a level field. More importantly, it keeps us from having to make tough decisions about failing students who may have mistaken the rules due to language barriers; it's easier to simply not accept a student than to fail one once accepted.
Google Group and IRC participation and blogging are mandatory on our student requirements. Since last year, we have made prior code pull requests mandatory, with documentation contributions as bonuses. We provide many simple issues (e.g. goo.gl/MDpKMi) in our trackers, which students may use as starting points. 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. Regular blogging about progress is also a requirement.
We encourage Google Group discussions rather than emailing mentors privately. The goal is to eliminate appearances of favoritism and to allow students to collaborate on proposals. Accepted students have often gotten some of their best ideas from discussions with other applicants (e.g. goo.gl/V5ntVU). Those unwilling to collaborate are generally seen as a bad fit for our community.
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 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 contribute - or participate in other projects. If they have negative experiences, we may never see them again.
Proof of our student retention methods paying off can be seen in the fact that four out of five GSOC students we had last year have volunteered to sign up as mentors this year. One of them has also taken up responsibility to be the org admin. These results show that SciRuby is able to use GSoC as an effective catalyst for transforming students into full participants in our community.
SciRuby has participated for the last three years in Google Summer of Code; for the first two years we had four students, and five students last year, and none have failed. Many successful students have kept contributing to SciRuby projects through the year, and have signed up as mentors this year.
We have given slots away every year we participated if we felt that a student might not make it through GSOC, in spite of having a very good project.
2011
We believe in creating an environment which is welcoming for underrepresented groups. We filter applicants by asking a specific "bonus" question (www.goo.gl/vfdXSv). If applicants make a joke (not uncommon), we use it as an opportunity for dialogue — and most later provide much more thoughtful answers. A number of applicants provided insightful responses immediately. We do not accept students who are likely to create a hostile environment for others.
Potential students who want to apply to SciRuby for GSOC 2016 can go through these proposals of previously accepted students to get a better idea of the quality of proposals that we expect. Keep in mind that you can design your proposal as per your needs and style, but going through these should give you a better idea.
- @v0dro - Increasing the capabilities of daru
- @abinashmeher999 - Ruby bindings for SymEngine(previously known as CSymPy)
- @dilcom GnuplotRB - Redesigning Ruby Gnuplot bindings
- @agisga - Adding Linear Mixed Effects Models Support to SciRuby; project proposal, rest of GSoC application
- @wlevine - Create new nmatrix gem for advanced linear algebra features