Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # general >> Re: [vote] Incorrect definition of lazy consensus in by-laws?


Copy link to this message
-
Re: [vote] Incorrect definition of lazy consensus in by-laws?
I personally am fine with simply changing the name in the by-laws to
"consensus approval".  Looking at the by-laws there are three places that
currently list "lazy consensus" as the voting mechanism.
Adding/reinstating a PMC member, adding/reinstating a committer, and
making a code change.  The code change already has an addendum to make it
so that there is only one +1 needed and that the waiting period can be
non-existent, so it is really its own form of voting.  For the PMC actions
I think 3 +1s is an OK barrier to meet.

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.

I am +1 (binding)

--Bobby

On 3/21/13 12:45 PM, "Noah Slater" <[EMAIL PROTECTED]> wrote:

>Specifically to address your last comment, that the definition doesn't
>seem
>too bad... I agree that the concept as describe is a good one. But we have
>another name for that: consensus approval. The definition is bad because
>it
>calls this process "lazy consensus", but this already has an established
>meaning within the foundation.
>
>
>On 21 March 2013 17:37, Matt Foley <[EMAIL PROTECTED]> wrote:
>
>> There's an alternative viewpoint on this, which is that sometimes it is
>> best to do nothing.
>> And if a proposal can't scrape up 3 lousy +1's out of 58 committers (or
>>35
>> PMC members),
>> it's probably best to let it die a natural death.
>>
>> So the current definition doesn't seem bad to me.
>> --Matt
>>
>>
>> On Thu, Mar 21, 2013 at 10:15 AM, Noah Slater <[EMAIL PROTECTED]>
>>wrote:
>>
>>> [1] http://www.apache.org/foundation/glossary.html
>>>
>>>
>>> On 21 March 2013 17:15, Noah Slater <[EMAIL PROTECTED]> wrote:
>>>
>>> > Just thought to check the foundation's glossary of terms[1], and
>>>found:
>>> >
>>> > 'Consensus approval' refers to a vote (sense 1) which has completed
>>>with
>>> >> at least three binding +1 votes and no vetos.
>>> >
>>> >
>>> > This is what Hadoop is calling "lazy consensus", which is defined in
>>>the
>>> > above document as:
>>> >
>>> > A decision-making policy which assumes general consent if no
>>>responses
>>> are
>>> >> posted within a defined period.
>>> >
>>> >
>>> > For context, I originally brought this issue up on the CloudStack
>>>lists.
>>> > But I was told that CloudStack copied it's initial by-laws from
>>>Hadoop.
>>> And
>>> > maybe other incubating projects are doing the same. So it seems
>>> important
>>> > to fix.
>>> >
>>> >
>>> > On 21 March 2013 17:11, Noah Slater <[EMAIL PROTECTED]> wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I was just reading through the by-laws[1] and it occurred to me
>>>that we
>>> >> might have the wrong definition of lazy consensus.
>>> >>
>>> >> Specifically, we define it here:
>>> >>
>>> >> "3.2.1. Lazy Consensus - Lazy consensus requires 3 binding +1 votes
>>>and
>>> >> no binding -1 votes."
>>> >>
>>> >> My understanding of lazy consensus is that it requires no votes
>>> >> whatsoever. In fact, there are two modes. The first is to simply do
>>> >> whatever it is you think is a good idea, and assume someone will
>>>speak
>>> up
>>> >> if they disagree. The other is to state your intention, and give 72
>>> hours
>>> >> for people to object. If you receive no objections, you proceed.
>>> >>
>>> >> Neither of these situations require any votes. And in fact, the
>>>primary
>>> >> idea behind lazy consensus is that if you hear nothing, you can
>>> proceed.
>>> >>
>>> >> Here's a good page about it:
>>> >>
>>> >> http://rave.apache.org/docs/governance/lazyConsensus.html
>>> >>
>>> >> If you look on the foundation's page[2] on voting, you even see
>>>things
>>> >> like this:
+
Aaron T. Myers 2013-03-21, 21:44
+
Noah Slater 2013-03-21, 21:53
+
Uma Maheswara Rao G 2013-03-22, 05:45
+
Noah Slater 2013-03-23, 17:17
+
amareshwari sriramdasu 2013-03-22, 04:56
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB