GOP-PROP 2: mentors and Frogs

[Graham Percival]

Discussion begins.  I expect a moderate amount of discussion and
changes to this proposal; it will not be as clear-cut as
GOP-PROP 1.
http://lilypond.org/~graham/gop/gop_2.html


GOP 2 - mentors and Frogs
Proposal summary

Many new contributors expect more help than they’re getting. We
should either:

   1. give them more help, or
   2. tell them up-front that they won’t be getting help. Think of
a roller-coaster entrance sign, but instead of saying "you must be
THIS tall to ride", we say "you must be THIS smart" or "you must
be THIS much of an independent programmer to contribute". 

I would prefer to get people more help, but more than anything
else I want to make sure that volunteers have a realistic
expectation of how things will work.

I have discovered a truly marvelous proposal for giving them more
help, which this summary is too narrow to contain.


Rationale

I’ve had emails from 5-10 contributors/developers in the past year
who were concerned/upset/disheartened about not getting feedback.
It’s not just one or two people being whiny. We have a serious
problem.

That said, as far as I’m concerned, the problem is
miscommunication. As the GPL says, releasing source code does not
imply any warrantee. Existing developers are under no obligation
to do anything, not even to reply to questions about the source
code. Somebody spending 10 hours trying to figure out how the
website build system does not obligate me to spend 2 minutes
replying to his emails. (I personally will respond to such emails,
but that is a matter of indivdiual choice – and if I was under any
obligation to reply, I would instead quit the LilyPond project
immediately)


Trade offs and finding a balance

Even if a significant number of developers were willing to spend a
significant amount of time mentoring new contributors, it’s not
clear that this would be a net gain to the project. If a new
contributor requires 2 hours of mentoring, does work that would
take his mentor 10 minutes to do, then leaves, then it’s a net
loss to the project.

It’s impossible to give any kind of accurate estimate about how
much development effort we "lost" to mentoring and
programs+policies to make things easier for new contributors. Most
developers don’t have a strict policy of X hours for lilypond per
week, so if they spent Y hours helping beginners, we can’t assume
that they would have spent Y hours fixing bugs instead. In
addition, there’s a fairly weak correlation between "time spent
programming" and "quality of code".

My vague estimate, based on reading lilypond-devel and looking at
git commit messages for the past year, is that we lost 5-15% of
developer effort towards helping new contributors, and we gained
about 20-30% from contributors. In other words, I think that our
current amount of new contributor-friendliness provided a benefit
to the project, but not an overwhelming one.

For the record, I do not dispute that most (over 50%) of the "most
active" (no precise definition here) developers required little or
no mentoring. That is a general rule true of almost all
open-source projects, and LilyPond does not break that profile.
But this does not imply that we should give no help at all; there
are still many people who could become extremely valuable
developers if they had a bit of mentoring to begin.

More background reading on this topic:

http://percival-music.ca/blog/2010-08-01-sustainable-development.html
http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
http://percival-music.ca/blog/2011-06-11-lilypond-2.14.html


Proposal details

I’m not suggesting that we give new contributors as much help as
possible; we need to find a good balance. Let’s make a three-stage
process:

   1. Frog ("apprentice"): any newcomer is directed to the frog
mailing list, and the Frog Meister will "mentor" all frogs. The
Frog Meister is not reponsible for any technical skills or patch
reviewing. He is expected to explain how to use lilydev and upload
patches to Rietveld, but other than that he is responsible for
"pastoral care" – does the contributor feel involved, does he have
somebody to talk to, are there enough people reviewing the
contributor’s patches, etc.

      Carl has agreed that he is "too square" to undertake such a
role, so I’d be looking for a volunteer for this position. The
Frog Meister does not to have git push ability.

   2. "Journeyman": after some amount of work (2-3 months? 5-10
patches?), a developer will offer to mentor a Frog. Exact details
are left up to each frog-developer pair, but the basic idea is
that the frog should have shown that he is serious enough to
warrant such attention+time from a skilled developer.

      Potentially we could even have a "journeyman" officially
mentoring another "journeyman", but at the moment I think it would
be enough to encourage them to still participate on the frog
mailing list.

   3. Developer ("master"): somebody with git push ability. You
know how things work (or not); your patches will hopefully get
added to the patches list and go through countdowns, etc.

      If it took you a lot of pain to reach this stage, then
hopefully you’ll consider mentoring one or two people.

I think the guidelines for mentors are still good, but I’m not
certain if we’ve been following them. For that matter, I’m not
certain how many actual contributor-mentor pairs we have – we
certainly don’t have a tradition of these – so maybe the whole
question is premature.
        
http://lilypond.org/doc/v2.15/Documentation/contributor/mentors


Implementation notes

Graham should keep track of all contributor-mentor pairs, and
maybe even have weekly discussions with mentors about how their
contributors are doing. (see the gnome.org/blosh/ blog post)

No technical implementation needed; we already have the frogs
mailing list, and if IRC or voice chat would be useful, such
infrastructure already exists. 


Cheers,
- Graham