-
Notifications
You must be signed in to change notification settings - Fork 79
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
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.