lilypond mentors started

[Graham Percival]

I've added the below material to CG 1 introduction.  I'd really like
to get going with this; is anybody else willing to mentor?  In
particular, I'm looking for doc and translation people.
1.  Doc mentors: this will let me spend more time on the build system,
new website, GUB, and the like.
2.  Translation mentors: as he mentioned a few hours ago, this will
let John spend more time on the build system, new website, and the
like.

Colin and James: I'm your mentor.  You can expect me to reply to
emails within a day.  I think you know your current tasks.  It's now
your responsibility to inform me if you're uncertain about anything,
or willing to do more, or whatever.  (see below)


-devel list: I'm trying not to sound arrogant, but I think the
lilypond community would be better served if I spent more time on the
website, releases, etc., instead of reminding new doc workers to put
two spaces after a period and avoid referring to the reader directly.
However, I feel strongly that new contributors should have a dedicated
person to give them guidance (even if they never ask for help, they
should know there's somebody to turn to), so if nobody wants to take
over those two, I'll keep on prioritizing them over everything else I
do.
I know that we've gotten a bit disheartened by people offering to work
on the docs but then disappearing; I don't think this will happen
here.  They've both sent me git patches.  They might need reminding to
stay within 50 characters or avoid adding whitespace errors, but other
than that I consider them housebroken.  The hardest part of new
contributors is over, so if they were going to give up, I think this
would have happened already.  They _will_ need to be reminded to read
the doc chapter of the CG, and they _will_ make mistakes (there's a
lot of policies in there), but I don't think it'll be a lot of work.

Jonathan: I rejected your offer of help before, since I thought you
should have more time to recover from your tendonitis.  If that's been
going well, and if you're willing, I think you would be a great mentor
for them.  I don't need you to type a lot -- don't fix their patches
for them; either push the patch, or send them an email telling them to
"re-read the doc policy page, especially the 4th point" or whatever.
They both seem bright, so I'm sure they can deal with a
slightly-cryptic reply if that saves you a lot of typing.


--------- CG 1.4 Mentors -----
We have a semi-formal system of mentorship, similar to the medieval
“journeyman/master” training system. New contributors will have a
dedicated mentor to help them “learn the ropes”.

Note: This is subject to the availability of mentors; certain jobs
have more potential mentors than others.
Contributor responsibilities

   1. Ask your mentor which sections of the CG you should read.
   2. If you get stuck for longer than 10 minutes, ask your mentor.
They might not be able to help you with all problems, but we find that
new contributors often get stuck with something that could be
solved/explained with 2 or 3 sentences from a mentor.
   3. Send patches to your mentor for initial comments.
   4. Inform your mentor if you’re going to be away for a month, or if
you leave entirely. Contributing to lilypond isn’t for everybody; just
let your mentor know so that we can reassign that work to somebody
else.
   5. Inform your mentor if you’re willing to do more work – we always
have way more work than we have helpers available.

Mentor responsibilities

   1. Respond to questions from your contributor(s) promptly, even if
the reponse 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 thay 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.

--------------

Cheers,
- Graham