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(a)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?
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation