Re: GOP-PROP 2: mentors and Frogs

[Graham Percival]

On Wed, Jun 15, 2011 at 08:23:00AM +0100, Trevor Daniels wrote:
> 
> Graham Percival wrote Wednesday, June 15, 2011 12:14 AM
> Subject: GOP-PROP 2: mentors and Frogs
> 
> >  1. Frog ("apprentice"): any newcomer is directed to the frog
> >mailing list, and the Frog Meister will "mentor" all frogs. The
> 
> The Frog list should be the basis for *all* stages of mentoring.
> Look at the merits:
> 
> a) all questions and answers are seen by all, so all learn
> b) questions can be answered by Frogs and developers alike
> c) many developers read it, so questions are more likely to
> be answered
> d) someone who immediately knows the answer is likely to
> answer quickly, saving others the time needed to work it out
> e) unaffected by individuals going away
> f) cultivates a community spirit
> g) etc ...

Yes, but there are also demerits:

alpha) beginners may feel shy about asking questions publicly, or
at the very least, they may be "less chatty" than they would be in
private email

beta) mentors may feel constrained in their public+archived
responses

gamma) a general mailing list diffuses the "responsibility" of
answering.
http://en.wikipedia.org/wiki/Bystander_effect

delta) a private personal connection can foster more of a personal
bond between the two people


That said, I agree that we should be encouraging more people to
use the frog list more.  I just think that we need mentors+frog
meister as well.

> >     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.
> 
> I'm not convinced we need a Frog Meister.  Anyone capable
> of developing a patch to LilyPond code is capable of uploading
> it to Reitveld.  Any help required could be given on the list by
> any of the contributors.

Frog Meister, under this (re)interpretation, is more of a social
position than a technical one.


Perfect example: two weeks ago, issue 1630 chord autosplit  was
almost finished (it only needed a few minor code formatting).  But
then it stalled until I suggested to Janek that he should get in
touch with Karin 2 days ago.  Then suddenly stuff started
happening.

I think the story of this patch 
http://code.google.com/p/lilypond/issues/detail?id=1630
http://codereview.appspot.com/4490045/
is a horrible black eye for us.  Initial patch sent on 2011-04-29.
Janek said (in private email) that he could mentor her on
2011-04-29, but the patch only went on rietveld on 2011-05-07
because he was on vacation.  A few comments, then nothing happened
for two weeks.  Then a few more revisions happened, followed by
another two-week gap.

This whole patch could have been done in 5 DAYS if we'd had our
cards in order.
- new contributor comes.
- "welcome, here's the guidelines, ask on frogs or xyz for
  personal help"
- revision 1, comments for 24 hours, revision 2, comment for 24
  hours, revision 3, patch review countdown 48 hours.

Instead, this has dragged out for almost 7 WEEKS.  Given this
experience, I fully expect Karin to abandon any attempt at future
bugfixing in lilypond.  Seven weeks for a 68-line patch?!

Now, there was some initial miscommunication with Janek (going on
vacation), and with everybody still sorting out the patch review
process.  But I think it's worth looking at this disaster and
trying to learn from it.

At the moment, the patch is derailed due to our lack of automatic
C++ formatting, but that will be handled in next week's GOP.
Other than that, I think it would have benefitted from a dedicated
mentor.  Somebody who knows our development process and really
keeps tabs on the issue.  If Karin thinks that the patch is ready,
then the mentor should be making sure that people review it.  If
the patch gets a "LGTM, but indent xyz" then the mentor should
make sure that patch-writer knows how to go about it.


More than anything else, the mentor (or frog meister, for those
without mentors) should be somebody who CARES about the patch.
(or at least, "somebody who demonstrates that they care about the
patch", or at the very least, "somebody who demonstrates that they
pretend to care about the patch").

Because as a general rule, coming from years of observing lilypond
development, we *don't* care about patches or new contributors.

(maybe this is a touchy-feely girly thing that no self-respecting
hacker would admit.  Blame it on my long hair!  :)


> >  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.
> 
> I'm not convinced this it working,

I'm convinced this is not working.  :)

> or even that it could work.  Many do-called skilled developers
> are skilled only in certain areas.  If these don't happen to
> coincide with the area in which a Journeyman is working it
> becomes inefficient, ineffective and frustrating.  Better to
> continue to use the Frog list so many developers can respond.

Yes and no.  I totally agree that a Journeyman should have a
mentor in his area if possible.  But if not possible, I think that
simply having somebody who pretends to care about the
contributor's patches would be a huge step forward.


> >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.  I think the payoff here is not worth your effort.

Well, my effort in the case of 1630 was sending a 9-line email to
Janek, and that caused another flurry of activity.  That email had
my best payoff-vs-effort in months!  :)

More generally, I'm thinking of a text file (or maybe webpage or
CG section) that lists mentors, and once a week or once a month
I'd send an email to them asking if they're still in touch with
their contributor(s).

Cheers,
- Graham