Skip to content

Google Summer of Code 2014

Carlos Agarie edited this page Feb 6, 2014 · 4 revisions

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 is created. 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, such as 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.

What is your plan for dealing with disappearing students?

We have two project leads, Pjotr and John, who serve in the roles of monitoring and encouraging both mentors and students. Mentors are expected to communicate several times weekly with students. The project leads follow up to ensure that students are pushing enough code and are accounting for time spent doing research on their tasks. Students who repeatedly fail to account for their time are first questioned to address any problems. We will fail students on malperformance; students and mentors should understand that GSoC is a serious commitment. Even so, in our first year we believe we did well. Our selection process is geared towards early student involvement and during the program we meet online as a group and rotate code reviews between mentors and students so as to leave no student in isolation.

What is your plan for dealing with disappearing mentors?

Mentors are monitored for performance by students, mentors and org admins. That is one reason we have 2-monthly group meetings where projects are discussed. The org admins also actively interact with all students and invite comment. Co-mentors and org admins can substitute in for mentors who disappear, even temporarily. So far, our coding mentors have a track record of being responsive and available to GSoC 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. We are all part of the scientific community and behave as such.

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 weekly about their work (sciruby.com/blog and on their personal websites, which all of our students did last year). We actively tell students to take discussions to the mailing list and usually the community response is helpful.

What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?

By creating community that they feel a part of we hope to retain performing students. Check our alumni response to see what they say on our website. We have invited our students from GSoC 2013 back to participate as mentors this year, and plan to repeat that next year. Tracking our former students, we are convinced that even if students do not become long term contributors to our project they do learn to work in FOSS and tend to continue with other OSS projects in line with their GSoC work.

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 Open Bioinformatics Foundation (OBF) failed to get into GSoC last year, after three successful years training twelve students. We took in three of their experienced mentors. Their wisdom and drive helped us succeed and suggests that the OBF trains mentors well.

Aprotim Sanyal is a Googler who can vouch for SciRuby's co-lead, John Woods.

The JRuby organization can also vouch for SciRuby.

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 mentors from the OBF/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 maximizing contributions to demonstrated needs in science. 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 (UX/UI). We will not be accepting projects which are speculative, or even good projects that lack sufficient justification, and we will work more closely with our students to formulate designs prior to the coding start date.

A second challenge involves publishing. Both of our project co-leads changed employment this year, and that has made it more difficult to find financial resources to publish papers — which are essentially already written. This year, we plan to provide students with additional direction and encouragement toward publishing their work.

Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application?

?

Clone this wiki locally