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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
