We’re now mid-way through the first year of the AAAS Community Engagement Fellows Program (CEFP), funded by the Alfred P. Sloan Foundation. The first cohort of Fellows is made up of 17 scientific community managers working with a diverse range of scientific communities. As they continue to develop their community engagement skills and apply some of the ideas and strategies from their training, the Fellows will report back on the Trellis blog, sharing their challenges, discoveries, and insights. Today, Fellow Malin Sandström describes how a new project made a difference in her community.
Posted by Malin Sandström, Community Engagement Officer at INCF (International Neuroinformatics Coordinating Facility)
This summer, just above 1300 students have spent their time writing open source code for projects from over 200 mentoring organizations, within a program called “Google Summer of Code” that is run and sponsored by Google. I work for one of those 200 organizations. I have been involved in recruiting mentors and projects for us since 2013, and in charge of managing our participation since 2015. This is a fantastic program that has been of much value to us as an organization, and very enjoyable to work with for me personally.
Our first year as a mentoring organization, in 2011, we had 2 projects and a handful of applicants. After a few years of ramping up we now usually have 12-15 students each summer, chosen from a pool of 50-100 applicants. All students get to choose and adapt a favorite project from one of our ~25 project ideas proposed by mentors – usually active researchers – from our global community.
From a community manager perspective, this program is valuable in several ways:
1. Bringing in new community members
The most visible aspect is that the program brings a large number of new junior persons in contact with our community (which is based around a field of research, and as such tends to have few visible members below the level of PhD student). The program students are usually proficient in software development, but most lack experience in our research field. Besides training in code development, the program also emphasizes the community aspect of open source – students are expected to become active participants in the community they are joining, and learn and adapt to their specific community’s way of working and communicating. For this, the students get a generous stipend, coding experience, and at the end a project to showcase their skills.
Even if this is a volunteer effort, mentors and their labs also benefit. They get a token stipend, but the value is mostly in the work done on their project, and the contact with student developers from outside of their own networks. Most of our mentors have a constant need both for coding expertise and for finding a way to pay good students not in their university to work on a software project (I was surprised to learn that university regulations in many places makes paying students for work hard-to-impossible). Many mentors continue to involve the students after their projects have ended – this is also one of the expressed aims with the program – or pick up promising students who did not make it all the way through the very competitive selection process.
The practical drawback is that bringing over a hundred new persons into a community in a short time can be overwhelming and messy; it needs structure and the right kind of tools. Last year we gave up on our old mailing-list-based solution and moved the whole student selection and student-mentor interaction onto Trellis. Each project idea now gets its own discussion thread, so instead of mentors having to answer the same basic student questions over and over, past replies are visible to all and students are up to speed much faster. For me as project manager it gets much easier to see if students are getting replies on time, and as a bonus both I and mentors have some rough indication of which projects attract the most interest. Once projects and students have been selected, we move the 12-15 students to a new subgroup, where they are asked to post ultra-short progress reports each week. This way, mentors and org admins have a collected view of each project’s state.
2. Connecting existing members
A second benefit of the GSoC program is that discussing project and student selection brings our mentors, who may be far apart both geographically and subject-wise, in better contact with each other. Collaborating to propose and mentor a project of joint interest – for instance, one that makes two mentors’ tools compatible with each other – doesn’t require getting funded first, just finding time to regularly follow up with the student coder if your project gets selected. While competition between mentors could be divisive, in practice the generosity of the program also seems to inspire a similarly generous mindset of ‘let’s find the best solution for everyone’. Even possibly fraught and competitive situations, such as mentors competing for project slots or extra promising students, have several times been the starting point of new collaborations.
3. Empowering the community
But the best part is: by stepping into the role as a mentoring organization, which is largely an administrative activity that makes mentors’ tasks easier, we get to help our community help each other. Funding for development of software tools is hard to get, and even harder to keep. Many scientific software projects are therefore driven with none or sparse funding and there are a myriad of small gaps to fill in order to make tools better, faster and smarter. Since everything is required to be open source, the tools and improvements resulting from each Summer of Code are available to everyone in our wider community – even people who have never heard of the program benefit.
Learn more: Browse a list of INCF projects in the 2017 Google Summer of Code
You can find all of the CEFP Fellows’ posts here.