2016 Google Summer of Code Mentor Summit
The Google Summer of Code (GSoC) is a programme run by Google to sponsor the development of open source projects by university students between June and August (see our previous post Downloading Developers: The Google Summer of Code). After the summer, Google sponsors some GSoC mentors to meet in Sunnyvale, California, for a two-day summit where they can discuss what went well and what can be improved.
When we discovered that we would attend the summit (Raniere represented NumFOCUS and David represented Open Astronomy), we were happy to know in advance that a familiar face would be present. The summit kicked-off on a Friday. Mentors arrived in their respective hotels with their many (figurative) hats—not all attendees make their living from their projects (we don't). The summit followed the unconference style and its schedule for the next two days started to take form the same Friday night. To propose a session, participants needed to write their suggested session title on a huge post-it, go to the schedule wall and stick the post-it on. If needed, attendees can later change the time of their session, merge it with another one or cancel it as long as the change doesn't happen right before the session. All in a very organic fashion.
This year Raniere decided to propose two discussions. The first one was "Lower the barrier for students. Docker? Virtual Machines? AWS?" that had around 14 attendees who were, probably, attracted by the word "Docker" on the title of the session. On our 50 minutes slot, we discussed the experiences of the projects represented there on how to speed up new contributors (not only GSoC students) to have the source code running for the first time on their machines.
Setting up Docker containers or virtual machines with shared folders between host and guest environment can be more time consuming for first-time users than running "./configure && make && sudo make install" on the command line. However, virtualisation can help in cases when a specific version of some software is required or local services need to be configured. Remote machines need to be used when the project depends on the reply from third party web services (e.g. authentication or payment) or large datasets. Otherwise, they should be avoided since configuring the students’ IDE to work with files remotely (e.g., over SSH) can take some time, or some students can have slow internet connection.
The second discussion that Raniere proposed was "GSoC and science: How to outreach to non computer science students?" When Raniere was an applied mathematics student and wanted to participate in GSoC, he had some difficulties to find ideas that he could work on. Part of the reason was because some open source projects are under an umbrella organisation that he’d never heard about before. During the session, we found some suggestions such as using a common set of keywords or link to other mentoring organisations from your project ideas homepage. We also discussed workshops (like Software Carpentry, Data Carpentry, The Hackers Within, and others) as one way to upskill non-computer science students for GSoC together with Hacky Hour, local user groups or Meetups as one way to increase students confidence to participate in GSoC. One important comment was that many universities can "spam" their students with emails about local meetings or jobs offers (although GSoC doesn't classify as a job nor an internship).
Additionally to these two sessions proposed by Raniere, we also participated in other sessions. Two focused on community building we want to highlight were "Outreachy! Improving Diversity in your project" by Karen Sandler from Software Freedom Conservancy and "User docs for your project" by Ekaterina Gerasimova who contribute to Gnome. Karen's session was about the Outreachy programme that works like GSoC but targets people from underrepresented groups and is considered a winter internship. Applications for 2016-2017 are already closed but if you want to participate in future editions you can contact the Software Freedom Conservancy. The session also covered how to be more inclusive in your organisations, what you can do within your organisation to reach to the minorities, get passionate mentors and provide a safe environment.
A similar programme, named Rails Girls Summer of Code, was also mentioned. Ekaterina's session covered how Gnome handles user documentation processes that include draft, improvement, proofreading, and translation. Attendees in Ekaterina's discussion added information on how their projects handle user documentation and at the end pushed the discussion towards localisation. Here at the Institute, we strongly advocate for all projects to provide user documentation; otherwise it isn't sustainable. Thanks to Ekaterina, we can now provide better suggestions like "write your documentation with American spelling but British style since the former is better recognised but the latter is clearer". Additionally, documentation writers should also include the style rules that their project will follow (as Gnome) to help future contributors and translators.
Two sessions focused on tools that we want to highlight were "Event organisation with open source tools" by Mario Behling from FOSSASIA and "Zulip is open source group chat (like Slack)" by Tim Abbott from Zulip. At the event organisation session, we discovered an open source clone of Eventbrite, developed by FOSSASIA, and OSEM, which started being developed by openSUSE contributors to use during their conferences. Both solutions look great based on the demo their teams provided during the session, and I think that any group that organises many events should try to test the solutions1 given that both projects provide painless configuration powered by Heroku. Additionally, FOSSASIA's web application should be familiar to any member of your team that uses Eventbrite. Tim's session demoed Zulip, which is an open source chat solution based on Zephyr protocol that supports topic on top of channels. Topics can be used to organise the information, more or less like threads in your Gmail inbox, or just to avoid spam from some users.
A very important session within the GSoC frame was "How to Keep Students Contributing to Your Project After GSoC & GCI" run by Hong Phuc Dang from FOSSASIA. It's not uncommon that during this type of programs you get a student for your project who does an excellent job during that summer and then leaves, forever. However, there are lots of successful stories were the student evolves into a mentor and is so tied to that project that he/she then decides to do a PhD and even finds a job for life. The main idea of the GSoC programme is to find students that stick around because that's how open source survives, not by people who is paid, but by people who contributes in their free time. Throughout the session, we discussed how to transmit such interest from the mentors to the students and which "rules" each organisation have in place to "force" the students to tell the world about their work (blog post, public talks, etc.).
The sessions on the summit were great and mentors also had a great time at all times. We can't of course leave out the lightning talks where some mentors presented the work of the best mentees in their organisations.
If you’re looking for a diverse open source event like the GSoC Mentor Summit you should book your tickets now to attend FOSDEM on 4th–5th February 2017 in Brussels.