> On Jan 8, 2015, at 3:03 AM, jan i <j...@apache.org> wrote: > > On Wednesday, January 7, 2015, Alan D. Cabrera <l...@toolazydogs.com > <mailto:l...@toolazydogs.com>> wrote: > >> >>> On Jan 7, 2015, at 10:46 AM, jan i <j...@apache.org <javascript:;>> >> wrote: >>> >>> On 7 January 2015 at 19:32, Alan D. Cabrera <l...@toolazydogs.com >> <javascript:;>> wrote: >>> >>>> >>>>> On Jan 7, 2015, at 10:13 AM, Branko Čibej <br...@apache.org >> <javascript:;>> wrote: >>>>> >>>>> On 07.01.2015 18:42, Alan D. Cabrera wrote: >>>>>> I’ve written up a more comprehensive proposal that would not only hold >>>> mentors accountable but also give them a fair bit of autonomous >> authority >>>> during releases. >>>>>> >>>>>> https://wiki.apache.org/incubator/MentorRebootProposal < >>>> https://wiki.apache.org/incubator/MentorRebootProposal> >>>>>> >>>>>> What we would gain is transparency and simplicity. There would be no >>>> false expectations. Podlings would know where they stand. Work would >> be >>>> equitably distributed. >>>>>> >>>>>> No more layers. No more additional roles and confusing/diluted >>>> responsibilities. No more shuffling. >>>>> >>>>> What you're proposing, then, is that we institute mentor licenses with >>>>> requirements over and above those for ASF membership. In effect, you'd >>>>> create an additional level of earned merit for mentors ... which is >>>>> probably a good thing. >>>> >>>> I don’t think that I’m following. Mentors need to be members of the >> IPMC >>>> but that doesn’t mean they need to be ASF members. >>>> >>>>> What I don't understand is this: where's the motivation for anyone to >>>>> submit to this additional burden? There's a lot of stick in your >>>>> proposal, but a woeful lack of carrot ... so, most likely not going to >>>>> work for a bunch of volunteers. >>>> >>>> What extra burden? The proposal is not asking mentors to do anything >> more >>>> than what they shouldn’t already be doing. All the proposal does is >> hold >>>> the mentors accountable for their inactivity and to add more of an >>>> incentive for PPMCs to be proactive in their relationships w/ mentors; >>>> something that the PPMCs shouldn’t already be doing. >>>> >>>> The carrot for both podlings and mentors is that there is no second >>>> gauntlet of voting/review by the IPMC for releases. >>>> >>> >>> In general I like the proposal especially the carrot. But I do have a >>> couple of concerns: >>> >>> "An active mentor is removed from a podling if that mentor does not >>> review/sign off on a release. An active mentor is removed from a podling >> if >>> that mentor does not review/sign off on a board report." >>> >>> Can a mentor not take vacation ? I think this need to contain a clause, >>> that if the mentor has adviced the PPMC about the absence this will not >>> happen. >> >> Yes, they certainly can! All they need to do is notify the PPMC and IPMC >> that they are going to be inactive. :) > > well You say that , but the text does not state the same.
"A mentor is free to become inactive but must explicitly state this by notifying the PPMC and IPMC” and "An inactive mentor can become re-activated by simply notifying the PPMC and IPMC.” >>> "Being put on hold means that no committers can be added, no PPMC members >>> can be added, and no releases can be performed" >>> This would be a no go for me. If a podling has lost a mentor, but are >>> actively seeking a new mentor, the IPMC must step in to accept a new >>> committer, PPMC member or release. The IPMC has accepted the podling, so >> it >>> is very unfair, to punish a podling, that does a active job to replace a >>> mentor. >> >> If a mentor really goes MIA, should those things be taking place without >> mentor oversight? IMO, no. No, this is not punishment, this just makes >> the current state of affairs clear and explicit. Plus, the PPMC needs to >> take on a more active role in things; they are not teenagers in the back >> seat. > > > of course they would! first of all it only takes 1 mentor to do that not 2, > secondly > - new committers is the responsibility of the PPMC not the mentor > - PPMC is the responsibility of PPMC/IPMC not the mentor > - Releases is the responsibility of PPMC/IPMC not the mentor > according to our current documentation. > > I don't disagree with your proposal, I just want an escape clausal in case > a podling run into problems caused by our eager to over administrate. I have a strong distaste for escape clauses. It makes things needlessly complicated. If there’s an escape clause that states one mentor is good enough at times then we may as well have a one mentor minimum. The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Regards, Alan
