hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <tom.e.wh...@gmail.com>
Subject Re: [DISCUSS] Proposed bylaws for Hadoop
Date Wed, 20 Oct 2010 21:12:50 GMT
Thanks for the explanation Owen. The HttpComponents bylaws define
"majority" as "A majority decision passes if there is a minimum of
three binding +1 votes and at least 75% of the binding votes are +1."
So this is not the same as the 50% majority defined the the draft.
(Actually, I notice that only "lazy majority" is defined, not
"majority" in the approvals section.) I suggest we make this stronger.
By way of comparison, the recently enacted bylaws for Pig
(http://pig.apache.org/bylaws.html) have consensus, for example.

Also, Pig has a minimum length of time for each action, rather than
the same fixed number for each. Might be worth considering.


On Wed, Oct 20, 2010 at 9:54 AM, Owen O'Malley <omalley@apache.org> wrote:
> On Oct 19, 2010, at 2:46 PM, Doug Cutting wrote:
>> With the exception of these two bullets, these bylaws seem equivalent to
>> those posted by several other projects.  Most projects use consensus-but-one
>> for committer and PMC removal.  Was this change intentional or accidental?
> It was intentional. In my survey of other Apache project's bylaws, I was
> originally surprised to find some such as HTTP Components
> (http://hc.apache.org/bylaws.html) that use majority votes for removing
> people. However, the question is whether a small minority should be able to
> drain a project's attention and energy.
> For anyone who hasn't already seen it, there is an outstanding presentation
> on "Open Source Projects and Poisonous People" that was done by Brian
> Fitzpatrick and Ben Collins-Sussman. I'd highly recommend it.
> http://www.youtube.com/watch?v=ZSFDm3UYkeE. The presentation's central
> thesis is that a project's attention and energy are its most valuable
> resource. People that cause long emotional debates without contributing to
> the project are extremely destructive to the project and must occasionally
> be asked to leave.
> Of course everyone hopes to avoid these cases, but the question is whether
> the project should have the mechanism to fix itself. I feel that it must.
> -- Owen

View raw message