Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CA+z3+9Gp8FkOhPZwv6WH0v8v-Bw3VfzFGQn=kKQx5gQQnLwRuQ@mail.gmail.com>
References: 
 <CAPaJBx4KLfET1wJZG-gvAW63ajaxtTQBon9FYCYL_aAAapSz5g@mail.gmail.com>
	<CAPaJBx5EkTYMD8vud_LXocheCgdX=gafBaz1bN1s5Z6fxSnfBA@mail.gmail.com>
	<CAPaJBx41SdAnakrUbbze3915iRBOPVU4DXmUHz_dkyq+X=AYtg@mail.gmail.com>
	<CA+z3+9Gp8FkOhPZwv6WH0v8v-Bw3VfzFGQn=kKQx5gQQnLwRuQ@mail.gmail.com>
Date: Thu, 21 Mar 2013 17:45:58 +0000
Message-ID: 
 <CAPaJBx45VVY=8Msgkx5wpq5CkJa8dB5Ykba2YYWWfVXXkTXQzA@mail.gmail.com>
Subject: Re: Incorrect definition of lazy consensus in by-laws?
From: Noah Slater <nslater@apache.org>
To: Matt Foley <mfoley@hortonworks.com>
Cc: general@hadoop.apache.org
Content-Type: multipart/alternative; boundary=e89a8f646d15481ed204d872e9a2

--e89a8f646d15481ed204d872e9a2
Content-Type: text/plain; charset=ISO-8859-1

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 <mfoley@hortonworks.com> 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 <nslater@apache.org> wrote:
>
>> [1] http://www.apache.org/foundation/glossary.html
>>
>>
>> On 21 March 2013 17:15, Noah Slater <nslater@apache.org> 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 <nslater@apache.org> 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:
>> >>
>> >> "Unless a vote has been declared as using lazy consensus, three +1
>> votes
>> >> are required for a code-modification proposal to pass."
>> >>
>> >> i.e. Needing three +1 votes is an alternative to lazy consensus.
>> >>
>> >> Thoughts on this?
>> >>
>> >> [1] http://hadoop.apache.org/bylaws.html
>> >>
>> >> [2] http://www.apache.org/foundation/voting.html#LazyConsensus
>> >>
>> >> Thanks,
>> >>
>> >> --
>> >> NS
>> >>
>> >
>> >
>> >
>> > --
>> > NS
>> >
>>
>>
>>
>> --
>> NS
>>
>
>


-- 
NS

--e89a8f646d15481ed204d872e9a2--