It doesn't make sense to say "lazy consensus but [with extra conditions on voting]" because lazy consensus is very specifically defined as consensus through silence, i.e. something that requires no voting.
Some things Hadoop is probably already using lazy consensus for: wiki changes, any time someone says "I'm gonna do X, and I'll give it 72 hours for someone to object" but does not call a vote. If there are instances where you are voting on things, then you are not using lazy consensus. But that is fine of course! I am just suggesting we use the correct terminology. So if committers are voted in with 3 +1 votes and no -1 vote, then that is a consensus approval vote. So I think we should just call it a consensus approval vote, and not mix up terminology. On 22 March 2013 05:45, Uma Maheswara Rao G <[email protected]> wrote: > I think current procedure is good in Hadoop community to have minimum some > +1's approvals in votings. > In Hadoop we follow R-T-C policy. From the foundation voting policy "Lazy > consensus cannot be applied to code changes when the review-then-commit > policy is in effect." > In Hadoop we are following this with little modifications "Lazy consensus > of active committers, but with a minimum of one +1. " > > But for new committer addition > "◦New Committer > When a new committer is proposed for the project > Lazy consensus of active PMC members" > > So, here it may be contradicting the policy from Foundations definition. > So, is it make sense to change that as "Lazy consensus of active PMC > members but with 3 min +1 binding votes" ? > Here lazy consensus does not allow vetos and other condition expects min 3 > '+1'. With this we can change the definition of Lazy Consensus in hadoop > bylaws also same as foundation. > Sorry if I misunderstand some bylaws here. Please clarify to me. > > Regards, > Uma > ________________________________________ > From: Noah Slater [[email protected]] > Sent: Friday, March 22, 2013 3:23 AM > To: [email protected] > Cc: Matt Foley > Subject: Re: [vote] Incorrect definition of lazy consensus in by-laws? > > Swapping out "lazy consensus" for "consensus approval" seems to make sense. > But might it also be a good idea to specify how lazy consensus (as defined > in the ASF glossary, and as used throughout the foundation) can be used? I > presume Hadoop makes heavy use of lazy consensus. (This is a drive-by > posting on my behalf. I am otherwise not involved in your community.) > Examples would be a C-T-R policy, changes to the wiki, or any time someone > says "I plan to do X. If nobody objects in 72 hours, I will assume lazy > consensus." > > > On 21 March 2013 21:44, Aaron T. Myers <[email protected]> wrote: > > > On Thu, Mar 21, 2013 at 12:18 PM, Robert Evans <[email protected]> > > wrote: > > > > > So to make this official I propose that we change the term "lazy > > > consensus" to "consensus approval" (aka s/lazy\s+consensus/consensus > > > approval/gi) in the bylaws so that it matches the terms used in the > > apache > > > foundation glossary. > > > > > > As per the by-laws this would take a "lazy majority" of active PMC > > members. > > > > > > Lazy Majority - A lazy majority vote requires 3 binding +1 votes and > more > > > binding +1 votes than -1 votes. > > > > > > > > > Voting lasts 7 days, so it closes Thursday March 28th. > > > > > > > All sounds good to me, though I recommend you start a new [VOTE] thread > so > > that folks realize that this thread has moved on from a discussion into > an > > actual vote. > > > > -- > > Aaron T. Myers > > Software Engineer, Cloudera > > > > > > -- > NS > -- NS
