Re: PPMC voting new committers
Scratching my head as I assumed it was a normal non-tech vote conducted on the PPMC private list, majority wins, must be at least 3 votes. The one 'additional' rule I assumed was that the same must be true of PMC members voting; effectively the PPMC vote needs to include 3 mentor +1s. If a vote concludes with less than 3 PMC votes, it goes to the Incubator PMC private list to fill in the necessary votes. As the project moves closer to graduation, those mentor votes become more and more whackamole. Guessing I'm out of date :) I didn't know we had PMCs that were adding people via lazy consensus. Hen On Fri, Nov 3, 2017 at 10:34 AM, Craig Russell <apache@gmail.com> wrote: > I'd like to see a change in incubator policy w.r.t. voting new committers. > > While there are no Foundation policies on how to vote new committers, we > do have best practices documented in http://community.apache.org/ > newcommitter.html that explicitly calls for consensus approval of at > least three positive votes and no vetoes. > > Applying this to the incubator, it makes sense to me to change the > incubator policy to require a vote (no lazy consensus) and at least three > PPMC votes in favor. I'd also add a requirement for at least one Mentor > vote in favor. > > After graduation, communities might feel that they know better and can > adopt bylaws that are different from the community best practices. But > while in incubation I think that we should enforce best practice. > > Craig > > Craig L Russell > c...@apache.org > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: PPMC voting new committers
I'm of the opinion that if there isn't something broken, we should try to change it. Likewise, if there's a process in place that works well for TLP's I'm extremely hesitant to make something incubator specific. At the same time, I've seen the process break the way Craig's described. Coaching on list helps fix it. For instance, a podling I was mentoring was voting to add a new committer. It seemed partially coaxed by a mentor, however when I looked at what that person had done, it was 2 failed PR's (content changes targeting the wrong repo, where that repo is seemingly auto-generated from the source repository), an email asking how he can contribute, and two bug reports. One bug report did have a testcase fix (it was trivial, forcing locale into a consistent value). It's the kind of thing that makes me wary of the below email. I decided to not weigh in since a mentor had already voted +1, the guy seemed to be participating, granted still at a nascent level. I do think it would be good if we had more solidified processes for voting in committers. I agree with Craig's note, voting in a committer shouldn't be lazy consensus. Maybe we want to incubator guides with some recommendations but I do feel strongly it shouldn't become policy to require mentors to vote to add a committer. John On Sat, Nov 4, 2017 at 9:58 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote: > I'm of two minds on this: on one hand, in the beginning of the > incubation process something > like this certainly makes sense. Yet, towards the graduation we should > really encourage > the PPMC to behave more like a TLP PMC. As such they should have an > option NOT to > follow these somewhat arbitrary rules but instead come up with the > rules of their own > (within the foundation policy and doctrine of course). > > Not sure how to reconcile these two aspects. > > Thanks, > Roman. > > On Fri, Nov 3, 2017 at 10:34 AM, Craig Russell <apache@gmail.com> > wrote: > > I'd like to see a change in incubator policy w.r.t. voting new > committers. > > > > While there are no Foundation policies on how to vote new committers, we > do have best practices documented in > http://community.apache.org/newcommitter.html that explicitly calls for > consensus approval of at least three positive votes and no vetoes. > > > > Applying this to the incubator, it makes sense to me to change the > incubator policy to require a vote (no lazy consensus) and at least three > PPMC votes in favor. I'd also add a requirement for at least one Mentor > vote in favor. > > > > After graduation, communities might feel that they know better and can > adopt bylaws that are different from the community best practices. But > while in incubation I think that we should enforce best practice. > > > > Craig > > > > Craig L Russell > > c...@apache.org > > > > > > - > > 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 > >
Re: PPMC voting new committers
I'm of two minds on this: on one hand, in the beginning of the incubation process something like this certainly makes sense. Yet, towards the graduation we should really encourage the PPMC to behave more like a TLP PMC. As such they should have an option NOT to follow these somewhat arbitrary rules but instead come up with the rules of their own (within the foundation policy and doctrine of course). Not sure how to reconcile these two aspects. Thanks, Roman. On Fri, Nov 3, 2017 at 10:34 AM, Craig Russell <apache@gmail.com> wrote: > I'd like to see a change in incubator policy w.r.t. voting new committers. > > While there are no Foundation policies on how to vote new committers, we do > have best practices documented in > http://community.apache.org/newcommitter.html that explicitly calls for > consensus approval of at least three positive votes and no vetoes. > > Applying this to the incubator, it makes sense to me to change the incubator > policy to require a vote (no lazy consensus) and at least three PPMC votes in > favor. I'd also add a requirement for at least one Mentor vote in favor. > > After graduation, communities might feel that they know better and can adopt > bylaws that are different from the community best practices. But while in > incubation I think that we should enforce best practice. > > Craig > > Craig L Russell > c...@apache.org > > > - > 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
Re: PPMC voting new committers
Hi It sounds good to me. It's a good idea. Regards JB On Nov 3, 2017, 18:34, at 18:34, Craig Russell <apache@gmail.com> wrote: >I'd like to see a change in incubator policy w.r.t. voting new >committers. > >While there are no Foundation policies on how to vote new committers, >we do have best practices documented in >http://community.apache.org/newcommitter.html that explicitly calls for >consensus approval of at least three positive votes and no vetoes. > >Applying this to the incubator, it makes sense to me to change the >incubator policy to require a vote (no lazy consensus) and at least >three PPMC votes in favor. I'd also add a requirement for at least one >Mentor vote in favor. > >After graduation, communities might feel that they know better and can >adopt bylaws that are different from the community best practices. But >while in incubation I think that we should enforce best practice. > >Craig > >Craig L Russell >c...@apache.org > > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org
PPMC voting new committers
I'd like to see a change in incubator policy w.r.t. voting new committers. While there are no Foundation policies on how to vote new committers, we do have best practices documented in http://community.apache.org/newcommitter.html that explicitly calls for consensus approval of at least three positive votes and no vetoes. Applying this to the incubator, it makes sense to me to change the incubator policy to require a vote (no lazy consensus) and at least three PPMC votes in favor. I'd also add a requirement for at least one Mentor vote in favor. After graduation, communities might feel that they know better and can adopt bylaws that are different from the community best practices. But while in incubation I think that we should enforce best practice. Craig Craig L Russell c...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting in Committers
On Sun, Sep 29, 2013 at 7:39 AM, Alex Harui aha...@adobe.com wrote: The answer I got on members@ is that [1] is not a policy document and therefore a vote as to whether to make someone a committer defaults to majority rules unless the TLP has voted otherwise, and a -1 vote is not a veto unless the TLP has voted otherwise. On the contrary, I believe the default at Apache is that committer and PMC votes are by consensus, that a -1 is a veto. The rationale is that committers and PMCs must regularly reach consensus on code changes, so adding folks without consensus creates projects that cannot function. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Voting in Committers
Hi, This was already discussed on members@ but others in my TLP community are still not satisfied and want a more public discussion. I think the main question is whether [1] is a policy document and therefore satisfies the stated otherwise clause in this document [2]. The answer I got on members@ is that [1] is not a policy document and therefore a vote as to whether to make someone a committer defaults to majority rules unless the TLP has voted otherwise, and a -1 vote is not a veto unless the TLP has voted otherwise. And if that's true, would it be ok to be more explicit on [1] that it isn't a policy document? I know it says that Each project has different approaches to managing new committers but it still could mean that this is the policy unless the TLP has voted differently. 1. http://community.apache.org/newcommitter.html 2. http://www.apache.org/foundation/voting.html Thanks in advance, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Vetoing/Voting in committers?
Mladen Turk wrote: Justin Erenkrantz wrote: I'm not sure that a veto applies to whether we accept a podling or not. -- justin Justin's point is that a release can't be vetoed, a policy can't be vetoed. Code can be vetoed. So, if I happen to be a board member, then eventually I would have such an influence. As a member I should shout up, right? Remind me to run for the next board elections. A board's -1 here, e.g. if Justin voted -1, has just as much weight as your -1. Justin asks if it's a vetoable subject like code, or a concensus vote like new policy or releasing a tarball. That said, the original committee should be voting in new committers just like other projects do, and those commit bits should be granted based on merit. You can certainly include 'plays by the rules' and 'debates code not coders' and other basic civilized parts of participating in a project, in the 'merit'. And people in general shouldn't be discussed on this list. If we have a person problem, take it to the pmc. Folks names shouldn't be trashed on this list or any other public ASF list. Praise in public, chastise in private and all that. Last comment, we had the thought a long time ago about 'resetting' committers at the end of incubation, forming an official PMC and then having that PMC reassess the commit keys based on actual merit during incubation. I don't remember if that thread ever came to a conclusion. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vetoing/Voting in committers?
William A. Rowe, Jr. wrote: And people in general shouldn't be discussed on this list. Sorry about that. My bad :(. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vetoing/Voting in committers?
On Wed, 2006-06-21 at 15:46 -0500, William A. Rowe, Jr. wrote: Mladen Turk wrote: William A. Rowe, Jr. wrote: And people in general shouldn't be discussed on this list. Sorry about that. My bad :(. Mine too; and as the originator of the thread in public my apologies to Hani. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
