lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lilypond mentors


From: Graham Percival
Subject: lilypond mentors
Date: Wed, 30 Dec 2009 02:46:09 +0000

The Frogs have been around for a year, and I recently got two new doc
contributors, so I've been thinking about how things have been going
and some of the problems we've had.  I'm thinking about proposing a
(semi-?)formal system of mentors.

One thing I learned from GDP was that things work better if individual
people have individual responsibilities -- for the first four months,
I said "let's all look at {pitches, rhythms, etc} and fix stuff"; not
much happened.  After that, I switched to assigning one person to each
section, and that person took the editing effort a lot more seriously.

The mentors would be a similar thing: instead of having a general
Frogs list and asking experienced developers to help out in general,
we'll try to assign specific contributors (both programming and
non-programming) to specific developer-mentors.  The mentor will help
the contributor -- demystifying git, letting them know which file(s)
to edit, maybe finding problems for them to work on, etc.

Anybody interested in mentoring?  I'll take responsibility for
everybody not doing translations or programming.  At the moment, this
means James and Colin... that said, if anybody wants to take them on,
I can certainly find more work to do.

At the moment, we're not trying to gather more contributors; this is
just to retain the current ones and get them more productive.  GOP
(wherein we _will_ aggressively try to recruit more contributors) is
still slated for after 2.14 is out.  It would be good to test the
mentor system for a few weeks or months before that, anyway.


Here's material to to add to the docs.

in the CG:  (Introduction chapter?)
----------

Mentors

We have a semi-formal system of mentorship, similar to the Debian
mentors, Freebsd sponsors, and the medieval "journeyman/master"
training system.  New contributors will have a dedicated mentor to
help them "learn the ropes".

@warning{This is subject to the availability of mentors; certain
jobs have more potential mentors than others.}


Contributor responsibilities:  (FIXME: would a different name be better?)

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.


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.



on the website (help wanted: projects)
--------------------------------------

- "contributor spots": places available for documentation,
  translations (FIXME: check with John, or see if experienced
translators can serve as mentors for new ones), and anything other
than programming.  I don't know if we have any mentors available
for programming at the moment.



Cheers,
- Graham




reply via email to

[Prev in Thread] Current Thread [Next in Thread]