I perceive here that we have reached a favorite knot: the tension between 'mentor as coach' and 'mentor as supervisor'.
This PMC's job, as delegated by the board, is supervision. If the mentors don't supervise, who will? On the other hand, the very term, 'mentor', is much more suggestive of 'coach' than 'supervisor'. My proposal tries to deal with a bit of this by focusing on the champion, asking that person to sign up to at least feeling supervisory once a month. To those who felt potentially oppressed by my monthly micro-report, please recall: I proposed to glue that job to the champion, only bringing other mentors into it in case of need and by request. It has no routine monthly reporting requirement for mentors, per se. Ross' alternative, which has antecedents in previous discussions, goes in the direction I might label as "let 'mentors' be mentors", a bit, by formalizing shepherds to give consistent supervision. We could, ring any number of changes on that theme, including requiring every podling to launch with N mentors and M supervisors. I continue to hope for consensus on the thing I wrote. That does not make me opposed to Ross, or Alan, or any other thoughtful ideas about additional changes. On Wed, May 8, 2013 at 5:19 AM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > On Wed, May 8, 2013 at 10:47 AM, Ross Gardler > <rgard...@opendirective.com> wrote: >> ...I've made a proposal for giving the IPMC teeth but it hasn't gained >> support.. > > URL? > >> ...In the absence of something else with teeth then I'm +1 for >> probationary TLPs as proposed by Chris as long as we stop accepting >> projects that are likely to run into problems according to our >> collective experience.... > > If you're able to find out that a podling will cause problems in the > future, or that its mentors will become inactive, maybe I should hire > you for this lottery betting club ;-) > > Apart from that I agree that the board doesn't have cycles to handle > problematic podlings or missing mentors, and as a result whatever > actions it would take would be much harsher than what we do here. > > -Bertrand > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
