Re: GOP-PROP 2: mentors and Frogs

[Jan Warchoł]

2011/6/18 Graham Percival <address@hidden>
> Well, I'm not encouraged by the general disinterest in this topic.

I'm afraid it's because this problem isn't about finding some new
solutions or establishing a policy (like with C++ code formatting),
but about doing more work. *Maybe* someone will discover a great idea
that will help with mentoring, but i don't think it can be so easy.
It's rather about "we have to put more effort in mentoring. Who wants
to work harder and invest his time in a risky operation?" (as you
wrote mentoring is not always a gain to the project).

> 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.

I see that these are the same that we have in CG plus one new, about
weekly checks.

> [...]
> 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.

I suggest to write about Rietveld reviews explicitely. I also think it
should be mentor's responsibility, not a "very least option", to add
patch to 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 suggest one more: if you are working on something not very
difficult, ask your 'apprentices' to review *your* patches! In this
case "please review" would mean "please check if you can understand
what is going on here". Of course it would require that your code is
well commented. I see the following benefits:
- contributors become more involved
- contributors learn more about Lily internals
- contributors feel valued
- mentors learn how to comment their code well
- well commented code is much easier to maintain and improve.
(the last part is especially important to me because i spend more than
half of the time figuring out how things work, so i'd like to see all
code extensively commented; i suppose other Frogs can have similar
problems as i have).

Thoughts?
Janek