Re: GOP-PROP 2: mentors and Frogs

[Graham Percival]

On Wed, Jun 15, 2011 at 07:46:43AM -0600, Carl Sorensen wrote:
> This is especially tragic because the initial quality of the patch was very
> high.  Karin is clearly a gifted programmer who figured out how to solve
> this problem on her own.  Losing her potential contributions to LilyPond is
> a real problem.  I hope we can change our ways and continue to get her
> involved.

Well, I'm not encouraged by the general disinterest in this topic.
(although I know that Carl is suffering through a conference in
Hawaii, poor guy)

Maybe we'll just dump all newcomers on Janek?


Let's look at specifics.  Of people who have git access, what (if
anything) would make you consider being a mentor?  Not everybody
is cut out to be a teacher; if you don't feel comfortable in that
position, then it's best not to offer.

I'm not looking for somebody to say "I'll take one person" and
then have me assign them somebody at random.  Right now, I'm just
looking for a best-case theoretical scenario.  Maybe something
like "well, I've been working on ancient music recently, and I
live in Peru but have poor English, so I would only be willing to
mentor somebody working on ancient music who was fluent in
Spanish".


I've added the (proposed) mentor responsibilities to the GOP
proposal page:
http://lilypond.org/~graham/gop/gop_2.html

Here's the responsibilities for mentors.  Do any of these seem too
heavy?  We can relax/remove any that are a sticking point for many
people.

1. Respond to questions from your contributor(s) promptly, even if
   the response is just “sorry, I don’t know” or “sorry, I’m very
   busy for the next 3 days; I’ll get back to you then”. Make sure
   they feel valued.
2. Inform your contributor(s) about the expected turnaround for
   your emails – do you work on lilypond every day, or every
   weekend, or what? Also, if you’ll be unavailable for longer than
   usual (say, if you normally reply within 24 hours, but you’ll be
   at a conference for a week), let your contributors know. Again,
   make sure they feel valued, and that your silence (if they ask a
   question during that period) isn’t their fault.
3. Inform your contributor(s) if they need to do anything unusual
   for the builds, such as doing a “make clean / doc-clean” or
   switching git branches (not expected, but just in case...)
4. You don’t need to be able to completely approve patches. Make
   sure the patch meets whatever you know of the guidelines (for
   doc style, code indentation, whatever), and then send it on to
   the frog list or -devel for more comments. If you feel confident
   about the patch, you can push it directly (this is mainly
   intended for docs and translations; code patches should almost
   always go to -devel before being pushed).
5. Keep track of patches from your contributor. If you’ve sent a
   patch to -devel, it’s your responsibility to pester people to
   get comments for it, or at very least add it to the google
   tracker.
6. Contact your contributor at least once a week. The goal is just
  to get a conversation started – there’s nothing wrong with
  simply copy&pasting this into an email:
        
     Hey there,

      How are things going?  If you sent a patch and got a review, do
      you know what you need to fix?  If you sent a patch but have no
      reviews yet, do you know when you will get reviews?  If you are
      working on a patch, what step(s) are you working on?


I'm really hoping that we could get 3 people offering to be
mentors, other than Janek (who gets all the Frogs) and me (who
would rather be a meta-mentor).  I'm hoping to distribute 3-4
contributors amongst that group.  Certainly no more than 2
contributors per mentor, and ideally only 1.

Cheers,
- Graham