GSoC 2017 - Acceptance of Student Proposal

Sorry, your proposal was not accepted - read the title of Google Summer of Code's mail during the 2016 edition. Fast forward to May the Fourth of 2017, my proposal to Ruby Science Foundation ( Github | Website ) was accepted. So, what exactly changed between the 2016 and 2017 editions? A lot. This is exactly what this blog post is intended to document, for the benefit of GSoC aspirants who'd like to know on how to get started in this open-source program that is Google Summer of Code.

First things first, this might vary from time to time, person to person, and organization to organization - now that this acts as a disclaimer, feel free to continue reading.

Folks have quite a mixed bag of opinion regarding whether it is good to start contributing to a project even before the organization has been accepted for GSoC. This mixed bag is typically a risk-versus-return scenario, where some students 'take the risk' and get started with a project early because it's interesting, while many others feel that they can't risk their efforts. I believe in starting early, keeping in mind that nothing in open-source (or even life, for that matter) ever goes in vain.

• GSoC 2016 : I came to know about GSoC 2016 only after the organizations were announced.
• GSoC 2017 : I started my preparations right from January, i.e, even before the list of accepted organizations was announced.

In my opinion, starting early definitely does give you a decisive advantage simply because you have more time to get accustomed with the organization guidelines.

With a number of project ideas that're open for Google Summer of Code, it's really important to single down on the project idea that'd be most apt and interesting to you. It's generally good to take enough time to look at the projects and singling down based on your preferences.

• GSoC 2016 : The ony preference I had in mind was to look at web projects. As I hadn't singled down on a project, I applied for five projects without doing enough research / contribution to any of the projects.

• GSoC 2017 : Having started early, I had enough time to go through previous year projects and take an educated guess that they'll get accepted this year as well. My preferences this year was very clear - I definitely wanted only a Ruby project with optional inclusion of web aspect. I came across the project daru of Ruby Science Foundation, and the acronym was enough to convince me to single down on this project. (Yes, strange motivations)

Crack : Daru stands for 'Data Analysis in RUby', while also meaning 'Booze' in Hindi.

After having chosen the project idea, it's very important to get in touch with the mentors and the organization. Most of the organizations have a medium such as Mailing list, IRC, Slack, Gitter, etc. where all communications take place. Feel free to introduce yourself, express your ideas, and discuss with other members. It's also the best place to resolve any doubts / ambiguity regarding the project, but make sure that you've done your efforts in solving the issue on your own. It's good to stay active on these mediums.

Along with communication, another important aspect is contribution. Go through the project repository, read the README instructions to setup the repository locally and try fixing any of the issues mentioned in the issue tracker of the repository. This is important, as this reveals your familiarity with the project, as well as your consistent temparament in handling Pull Request Reviews.

• GSoC 2016 : I wrote just one mail to all the five organizations, introducing myself. There was discussion with only one organization regarding my project proposal - however, that too died down as I wasn't active on the mailing list. I was able to contribute only to that one project with documentation, and wasn't able to handle all the proposals with conviction.

• GSoC 2017 : I was active on the SciRuby organization's mailing list, and the quick responses from the mentors made me even more active on the mailing list. I was also able to get 6 Pull Requests merged by the proposal period, as I started early.

This is probably the most important and yet the most neglected step. While your contributions showcase your familiarity with the codebase, it's your proposal that showcases the vision you have for the project and how you plan to implement it. Most organizations do have a proposal template, and it's preferred to follow the template. And of course, include as many code samples as possible, along with a detailed and feasible weekly timeline schedule.

If you've submitted a draft early, you'll most probably recieve reviews from your mentors. It's not required to blindly accept the changes suggested in the review. But if you're not changing it, at least ensure that you discuss with your mentor(s), regarding why you feel that your initial draft method might be better than the one suggested in the review. In short, explore as many alternatives and express the thoughts that went in choosing a specific alternative over others. More detailed the proposal, the better your chances.

• GSoC 2016 : Drafting 5 proposals within a span of 10 days was tiring, and almost all my proposals were just generic (without following the proposal template) and lacked clarity in terms of both plan and timeline.

• GSoC 2017 : I had much more time to draft the proposal for my chosen project. I submitted an initial draft of 10 pages as per the proposal template, and was also able to discuss about the reviews suggested. With more reviews and discussions, came more details and clarity in the proposal. At the last day of submission, I submitted my 19-page proposal which looks much better than the initial draft.

If you've read through the whole article, you definitely do have enough endurance to ace the competitive selection that Google Summer of Code has. All the best! Feel free to comment below if you find this article useful.