Summer of Code 2012/management

Group:	Platform
Start:	2012-02-01
End:	2012-10-31
Team members:	Gregory Varnum as backup organizational administrator
Lead:	Sumana Harihareswara

Summer of Code 2012 was the 2012 edition of a community program sponsored by Google, allowing students to join the community as developers.

This page focused on internal management of the program by the 2012 admin for Wikimedia, Sumana Harihareswara. You can read the past status updates to understand how the program went; for future GSoCs and other similar programs, see Mentorship programs.

Timeline

Organisation applications begin February 27.
Organisation applications deadline March 9.
Student applications begin March 26.
Student application deadline is April 6.

timeline

GSoC management philosophy

This is where I (Sumana Harihareswara, manager of our participation in GSoC) am placing my thoughts on how we should participate in GSoC this year.

I'm doing this to fix some past problems. A lot of past GSoC projects and students just haven't worked out optimally; code never got reviewed and merged or polished to a releasable or deployable state, and students drifted away. I believe I spent at least 125 hours on GSoC last year, probably more. Eight mentors spent about 30-60 hours each. And our outcomes were not good enough to reward that investment; only one or two of those students are still active in our communities. And this problem didn't start last year; when I look at Summer of Code Past Projects I see a lot of missed opportunities for engagement and a lot of undirected or misdirected effort, and many names of students whom we never heard from again.

People are more important than code

As Summer of Code Past Projects and MaxSem's quantitative analysis show, we have only an okay track record of nurturing students into continuing members of our community and of merging good code into trunk and deploying it. The merge issues especially bother me because they lead to lessened morale among prospective volunteers and past GSoC students. So:

I'm more interested in promising continuing contributors, who are competent at development and passionate about our mission, than about the specifics of their proposals
Since the quality of a student's relationship with their mentor is a top deciding factor in whether they stay in the community, I'll be aggressively checking on mentor-student relationships throughout the spring and summer

Hands-on mentorship and management

I am going to be very hands-on in selecting students and mentors this year, and in managing the student-mentor relationships.

I will be selecting mentors based on my judgment of their collaborative and mentoring skills, setting up online meetings among students and among mentor-student pairs, and insisting on early and frequent public communication from students. This is in response to previous suboptimal experiences with students who went silent, or mentors who didn't talk with their students enough, or projects that went astray because the larger development community wasn't engaged with them and so code never got reviewed and merged.

The top predictors of students' continued interest in staying with the community after August 20th are the mentor relationship and how substantial their interactive engagement with the larger development community was. So I will be selecting mentors based on my judgment of their collaborative and mentoring skills, setting up frequent public online meetings for students and mentors, and insisting on early and frequent public communication from students. This means that I may ask certain potential mentors not to serve, and that I may decide against selecting students or student-mentor pairs because I judge them unlikely to succeed.

Quality over quantity, scope small

It takes the full Community Bonding Period (and then some) to get used to our processes. And I'd rather people dedicate July 22-August 20 to merging with trunk, pre-deploy review, testing, bugfixing, documentation of course, and other integration work. So we should encourage students to scope for more like 6 weeks than 12. A well-scoped project is a dream to run. Our chant should usually go, "Can you really do that in a summer?"

"Quality over quantity" also refers to our candidates. I also would rather have five students who are likely to achieve their goals and stick with our community, rather than five who are and three who aren't. We don't need GSoC to be an intake valve for people who are new to programming or version control; that's what OpenHatch is for. And fewer students means that we won't be swamping experienced code reviewers with work that just can't get done before August 20th.

Include MediaWiki-supportive technology?

We could either be fairly inclusive under our GSoC umbrella (mobile applications, wiki bots, Semantic MediaWiki family/bundle, etc.) or limit ourselves to the Wikimedia Foundation's key platform technology (MediaWiki core, extensions (and operations maybe?)). This is an open question. Inclusiveness potentially widens the net, but also weakens the organization's ability to strongly brand and market its participation in easy-to-understand pages and language, and splits the GSoC students among various communication channels and codebases, isolating and weakening them.

SMW is applying by itself this year.

Don't make Sumana a bottleneck

Sumana is a liaison but please don't make a habit of making her a bottleneck and waiting for her to approve your ideas. A good rule of thumb: use your best judgment in making a decision, and then cc her on the email so she has a chance to speak up.

Documents

Communications

https://blog.wikimedia.org/2012/03/16/project-ideas-students-and-mentors-wanted-gsoc-2012/
https://blog.wikimedia.org/2012/04/23/wmf-selects-9-students-for-gsoc/
Various February and March 2012 emails on the wikitech-l mailing list
Evaluating Google Summer of Code