This post is part of our series of guest posts from students, mentors and organization administrators who participated in Google Summer of Code 2016.
How we made this our best Google Summer of Code ever
This was our fourth year doing Google Summer of Code (GSoC), and
it was our best year ever by a wide margin! We had five hard-working students who contributed over 17,000 new lines of (very useful) code to our high-priority projects.
Students voluntarily started coding early and hit the ground running, with full development environments and a working knowledge of GitHub Flow-style pull request process. They communicated with one another and provided peer support. They wrote tests. Hundreds of them! They blogged about their work as they went, and chatted with other community members about how to design features.
All of that was amazing, and it was made better by the fact that we were accepting pull requests with new code twice weekly. Tuesdays and Fridays, I went through new submissions, provided feedback, and pulled new code into our master branch, usually publishing it to our production site once a week.
I don't know how other projects do things, but this was very new for us, and it's revolutionized how we work together. In past years, students would work on their forks, slowly building up features. Then in a mad dash at the end, we’d try to merge them into trunk, with lots of conflicts and many hours (weeks!) of work on the part of project maintainers.
What made this year so good?
Many things aligned to make this summer great, and basically none of them are our ideas. I'm sure plenty of you are cringing at how we used to do things, but I also don't think that it's
that unusual for projects not "born" in the fast-paced world of modern code collaboration.
We used ideas and learned from Nicolas Bevacqua, author of
JavaScript Application Design and of the
woofmark and
horsey libraries which I've contributed to. We've also learned a great deal from the
Hoodie community, particularly
Gregor Martynus, who we ran into at a
BostonJS meetup. Lastly,
we learned from
SpinachCon, organized by
Shauna Gordon McKeon and
Deb Nicholson, where people refine their install process by actually going through the process while sitting next to each other.
Broadly, our strategies were:
- Good documentation for newcomers (duh)
- Short and sweet install process that you've tried yourself (thanks, SpinachCon!)
- Predictable, regular merge schedule
- Thorough test suite, and requiring tests with each pull request
- Modularity, insisting that projects be broken into small, independently testable parts and merged as they’re written
Installation and pull requests
Most of the above sound kind of obvious or trivial, but we saw a lot of changes when we put it all together. Having a really fast install process, and guidance on getting it running in a completely consistent environment like the virtualized
Cloud9 service, meant that many students were able to get the code running the same day they found the project. We aimed for an install time of 15 minutes max, and supplied
a video of this for one of our codebases.
We also asked students to make a small change (even just add a space to a file) and walk through the GitHub Flow pull request (PR) submission process. We had
clear step-by-step guidance for this, and we took it as a good sign when students were able to read through it and do this.
Importantly, we really tried to make each step welcoming, not demanding or dismissive, of folks who weren’t familiar with this process. This ultimately meant that all five students already knew the PR process when they began coding.
Twice-weekly merge schedule
We were concerned that, in past years, students only tried merging a few times and typically towards the end of the summer. This meant really big conflicts (with each other, often) and frustration.
This year we decided that, even though we’re a
tiny organization with just one staff coder, we’d try merging on Tuesday and Friday mornings, and we mostly succeeded. Any code that wasn’t clearly presented, commits squashed, passing tests, and submitting new tests, was reviewed and I left friendly comments and requests so it could be merged the following week.
At first I felt bad rejecting PRs, but we had such great students that they got used to the strictness. They got really good at separating out features, demonstrating their features through clear tests, and some began submitting more than two PRs per week - always rebasing on top of the latest master to ensure a linear commit history. Sweet!
Wrap-up and next steps
The last thing we did was to ask each student, essentially
as their documentation, to write a series of new issues which clearly described the problem and/or desired behavior, leave suggestions and links to specific lines of code or example code, and mark them with the special “
help-wanted” tag which was so helpful to them when they first started out. We asked each to also make one extra-welcoming “
first-timers-only” issue which walks a new contributor through every step of making a commit and even provides suggested code to be inserted.
This final requirement was key. While I personally made each of the initial set of “help-wanted” and “first-timers-only” issues before GSoC, now
five students were offloading their unfinished to-dos as very readable and inviting issues for others. The effect was immediate, in part because these special tags are
syndicated on some sites. Newcomers began picking them up within
hours and our students were very helpful in guiding them through their first contributions to open source.
I want to thank everyone who made this past summer so great, from our champion mentors and community members, to our stellar students, to all our inspirations in this new process, to the dozen or so new contributors we’ve attracted since the end of August.
By Jeff Warren, Organization Administrator for PublicLab.org
