-
Notifications
You must be signed in to change notification settings - Fork 79
Google Summer of Code 2014
This is our mentorship application for Google Summer of Code 2014.
Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?
We are a dedicated group of scientists and engineers with a set of common values and aims.
First and foremost, we believe technological and scientific advances benefit from diversity and from the introduction of unique perspectives. In particular, open source and science both have gender diversity problems. If nothing else, that means we are failing to recruit people into science and engineering who are instead going into other fields. Our organization has a plan to recruit women, by providing prominent female mentors and role models, but we can't afford to do it on our own.
Secondly, we believe science should be open and accessible. Even open access journals have difficulty compelling their authors to release source code. If we can encourage younger scientists to freely share code, we make it more likely that they will share code when seeking tenure and long after. Ruby is an ideal language for open science because the Ruby community shares code as readily as it creates code. Currently, many younger scientists are drawn to Python or R, which – while possessing many of the necessary libraries – lack the culture that Ruby has so successfully promoted. We want to create incentives for young scientists to choose Ruby, that we might eventually "infect" science with Ruby culture. That starts with young people, and particularly those young people with intellectual and scientific curiosity.
Thirdly, we support common science infrastructure, which was a key theme at the Google Summer of Code 2013 Mentor Summit. Most scientists are so focused on their own work that they don't have time to write generalizable code for use by other researchers. As such, most scientists end up "reinventing the wheel" time and time again. We want to work on creating libraries that will work for all scientists and frees up researchers to work on really important things like ending cancer, mining asteroids, and eliminating neglected tropical diseases.
What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible.
We have two sets of mentors: code mentors and role model mentors. The code mentors are selected for familiarity with the projects and proposed ideas, and for their programming skills in relevant languages (Ruby, C, C++, Java). The role model mentors are primarily female scientists and engineers who are coders that have volunteered to advise — in particular — young women participating in our project. All of our selections are extremely responsive, positive, and dedicated. Our organization is not large, but we are fortunate to have some excellent contributors from which to draw. All of our code mentors at the time of this writing have served as GSoC mentors in the past. Our role model mentors are new to our project, but have served in other mentoring roles in the past; they are either Ph.D. students or current Ph.D. researchers.
We have two project leads, Pjotr and John, who serve in the roles of "bad Ruby-cop" and "good Ruby-cop." Both are also mentors. Mentors will be expected to communicate several times weekly with students, and project leads will follow up to ensure that students are pushing enough code or are otherwise accounting for time spent doing research on their tasks. Students who repeatedly fail to account for their time will be dropped; applicants should understand that GSoC is a serious commitment.
Just as Pjotr and John serve as bad cop and good cop with students, they can also serve in these roles with mentors. Furthermore, they can substitute in for mentors who repeatedly disappear. However, most of our coding mentors have a track record of being responsive and available to GSoC students — and those that don't were responsive as students. Our role model mentors, we believe, have been selected in part because they have sufficient moral ownership of their roles that they are unlikely to simply disappear.
What steps will you take to encourage students to interact with your project's community before, during and after the program?
Students will be required to keep their code on Github and contribute to discussions in the mailing list and possibly IRC. We expect students to blog about their work (sciruby.com/blog and on their personal websites, which all of our students did last year). While we do not currently require applicants to have submitted pull requests prior to the program, we are placing a great deal of emphasis on it this year. So far we have already had an uptick in project participation due to GSoC 2014, so it may be that we can make prior contributions a requirement.
What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?
We have already invited our students from GSoC 2013 back to participate as mentors this year, and plan to repeat it next year.
If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here.
The BioRuby project from the Open Bioinformatics Foundation vouched for us last year, but was not accepted. Aprotim Sanyal is a Googler who can vouch for SciRuby's co-lead, John Woods.
If you chose "veteran" in the organization profile dropdown, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year.
GSoC 2013 was a learning experience for SciRuby. We were extremely fortunate to benefit from the experience of a number of folks from the BioRuby project, and with their experience, we selected four excellent students (all of whom passed, and all of whom produced useful Ruby gems now available through SciRuby).
Our key challenge as a project is focusing on demonstrated needs in science. Last year, we adopted the orphaned BioRuby people — as previously mentioned — and slightly expanded our scope to include them, which meant accepting projects with narrower impact than would have been ideal. However, SciRuby is ultimately focused on infrastructure common to all science and engineering areas, and that has influenced our choice of project ideas this year — which are drawn from linear algebra, statistical modeling, and lab notebooking. We will not be accepting projects which are speculative, and we will work more closely with our students to formulate designs prior to the coding start date.
Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application?
?