-
Notifications
You must be signed in to change notification settings - Fork 80
Google Summer of Code 2019 Application
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, have been students with SciRuby previously.
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.
Historically, our mentors in any given year have either mentored with us in prior years, or have been deeply involved with the projects that they will now be mentoring — a trend that continues in 2018. This year, at least three of our mentors are previous GSOC students who have now chosen to mentor and enhance the projects they had started previously.
Incomplete projects have only once 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 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 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 fairer to simply not accept a student than to fail one once accepted.
Google Group and IRC participation and blogging are mandatory for students and mentors. We require that all students submit pull requests (including code, documentation is a bonus), and find that this mandate ensures applicants are fully engaged. We provide many simple issues (https://goo.gl/PkI5eZ) in our trackers, which students may use as starting points. Greater consideration is given to students who participate consistently for months over those who show up closer to the application period, but our primary goal is to gauge whether students can sit and crank out code. Regular blogging is also required.
We encourage Google Group discussions rather than private emails. The goal is to eliminate appearances of favoritism and allow students to collaborate on proposals. Accepted students have often gotten some great ideas from discussions with other applicants (https://goo.gl/CTpKRP, https://goo.gl/7CJPZv). Those unwilling to collaborate are generally seen as unfit 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. Our community has greatly expanded since GSOC 2016 and we now have the Ruby Association and various private companies providing funding and mentorship for SciRuby projects.
Proof of our student retention methods paying off can be seen in the fact that many of our current mentors, including the org admin, are past students. These results show that SciRuby is able to use GSoC as an effective catalyst for transforming students into full participants.
Yes
2012
https://github.com/SciRuby
For each year your organization has participated, provide the counts of successful and total students.
- 2013: (5/5) Monica Dragan (with PhyloSoC), Alberto Arrigoni, Ankur Goel, Will Strinz, Wan Zuhao
- 2014: (4/4) Nishida Naoki, Rajat Kapoor, Magdalen Berns, Lahiru Lasundun
- 2015: (5/5) Alexej Gossman, Will Levine, Ivan Evgrafov, Abinash Meher, Sameer Deshmukh
- 2016: (4/4) Prasun Anand, Gaurav Tamba, Lokesh Sharma, Rajith Vidanaarachchi
- 2017: (3/3) Prasun Anand, Atithya Kumar, Shekhar Prasad Rajak
- 2018: (4/5) Arafat Khan, Prakriti Gupta, Pranav Garg, Nilay Pochhi
We support diversity. We filter applicants by asking a specific "bonus" question (https://goo.gl/UkLzHv). If applicants make a joke, we use it as an opportunity for dialogue — and most later provide much more thoughtful answers. Students who might create a hostile environment for others are rejected.
We believe our low failure rate derives from our application and mentoring systems. With only one exception (involving extenuating circumstances), every student has achieved their major goals.
Tools for Scientific Computing in Ruby
BSD-3
Technology Tags ruby, c, c++, cuda.
visualization, artificial intelligence, parallel algorithms, data science, gpu computing, linear algebra
https://github.com/SciRuby/sciruby/wiki/Google-Summer-of-Code-2019-Ideas
SciRuby's purpose is providing science, numerical, machine learning, and visualization infrastructure for the Ruby Programming Language.
The SciRuby project is oriented towards providing computational research infrastructure for the Ruby Programming Language. 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, rubex, arrayfire-rb, rbcuda, 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 awarded the Ruby Association Grant in 2014, Rubex and tensorflow.rb received it in 2016 and RbCUDA in 2017.
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. In fact, all the grants issued by the Ruby Association (which is headed by Matz) in 2016 (and most in 2017) have gone to scientific projects.
Since we are first and foremost a science-related project, we expect successful student projects to lead to publications. Better yet, students might get to see their code go into orbit, or used to save lives in biomedical research.