TL;DR: we're improving at student retention but need to get better at producing something useful at the end of a mentorship period; some suggestions follow.
On 08/28/2012 04:44 AM, Finne Boonen wrote:
On Tue, Aug 28, 2012 at 9:41 AM, Ryan Lane rlane32@gmail.com wrote:
I think you touch the most important point here. I'm one of the main people who manage GSoC for KDE. KDE is the biggest org taking part in GSoC this year in terms of number of students mentored. In addition we are running our own program (Season of KDE) next to it. So in total I'd say we've mentored about 100 students through these programs this year alone. We didn't get there by accident. You know what the main benefit of GSoC is in my opinion? Getting an organisation into the mindset of mentoring - into the mindset of "yes we need to train new people because they can do awesome things even if they screw up sometimes on the way there".
+1000. I <3 that way of thinking and I'd very much like our community to have the same attitude towards GSoC. We're a community working towards education of the world. Participating in GSoC as a mentoring organization is a right fit.
Agreed.
GSoC imho is not about getting code written but getting people involved in our community. As such we should look and see how many people remain involved after GSoC.
Finne
It has now been three months since the "pencils down" late in late August when GSoC 2012 officially ended. Therefore it's a good time to look at the nine students we accepted to see how many are still involved with MediaWiki, how many of the GSoC projects themselves are anywhere near what their original targets were, and whether we would prefer to try this again next year or go for a different approach to outreach and mentoring.
The answers: * seven of the nine students are still actively working on MediaWiki development. This is better than last year -- at this time last year, only about 2-3 of the eight accepted students remained involved. * one project hit its target (including merge into trunk) and about four others are partially merged into trunk and still have momentum towards completion. This is a little better than last year; about 2 projects from last year are fully merged into trunk and about 1 more is partially merged but there's no momentum towards the finish.
https://www.mediawiki.org/wiki/Summer_of_Code_2012/management reflects how I wanted to run this year's GSoC. I think we did well at "People are more important than code" selection, which is one reason we're doing well at retention. But I failed at ensuring that students were scoping their proposals at about 6 weeks of coding work and dedicating the entire last month of the summer to bugfixing and code review. The proposals usually allotted either no time or about 2 weeks for merging with trunk, pre-deploy code review, and integration. I think smaller scoping would have helped, so in the future, we should simply not accept proposals that do not allot at least a third of the summer to code review and response to code review.
I also failed at staying hands-on enough in ensuring frequent mentor-student communication. Having multiple hands-on mentors who were available to do code review REALLY helps, as we see from Nischay Nahata's success (he is our only student this year who got all his project code merged), and I think that in future years we should mandate that all students have two mentors, each of whom commit to reviewing new patchsets within 2 business days. Students can't afford delays in code review. The WMF is improving how it makes time for its engineers to mentor newer contributors (more on that this week) and that will help with this; we're also growing experienced volunteer developers who are interested in mentoring, so I think a 2-mentors-per-student mandate is doable. We should also mandate twice-weekly voice or videocall meetings and do spot checks to ensure they're happening; multiple students didn't have enough communication with their mentors and were shy about pushing for it.
Now, to discuss future mentoring approaches:
I tried to get us into UCOSP again for fall 2012 and was told they were out of slots, so I'm pushing to get us into UCOSP for spring 2013.
We couldn't muster enough mentors to do Google Code-In well so we aren't doing it this year.
Quim Gil is the administrator for our participation in the Outreach Program for Women, so I'll let him discuss how he wants to manage that and how he'll be setting expectations appropriately. :-) I think mandating two mentors per participant is a very good idea, Quim, what do you think? Also: instead of making newbies write fixed proposals with schedules, these OPW internships can follow broader charters and flex to accommodate students' interests and abilities, and it's easier to rescope iteratively to ensure that something useful gets produced by the end of the three months. The fact that some of the internships will be in marketing or communications will help with this, as it's easier to get fast critique of those deliverables. (Also, participants don't have to be students, so some of them will be more mature!)
And regarding future Google Summer of Code management, Yaron Koren wrote:
So here is my proposal: there should be in place some plan of action, ideally for every project, in case it goes overlong and doesn't get completed in time. That can take several forms: a commitment by the mentor or another experienced developer to finish up the project; a commitment by the WMF to fund the student to finish it, if the student turns out to be serious and it's just a simple lack of time that was the issue; a commitment by the WMF to fund someone else to finish it or just a commitment by the student to finish it themselves, on a volunteer basis. The last of those is tricky, because that tends to be the conclusion at the end of uncompleted projects anyway - the student keeps working on it, but that usually only lasts for a few months before the student's school work and/or regular work get in the way, and then the project often falls by the wayside. A commitment on the WMF and/or mentor side would be the ideal thing - and if there's no such guarantee for a specific project, then that should be taken into consideration when deciding on whether to accept it.
This is worth discussing when we decide whether to apply for Google Summer of Code 2013 (if Google decides to run it again).
Does anyone particularly agree or disagree?