Apache Hadoop Project Bylaws

This document defines the bylaws under which the Apache Hadoop project
operates. It defines the roles and responsibilities of the project,
who may vote, how voting works, how conflicts are resolved, etc.

Hadoop is a project of the <a
href="http://www.apache.org/foundation/">Apache Software
Foundation</a>.  The foundation holds the trademark on the name
"Hadoop" and copyright on Apache code
including the code in the Hadoop codebase. The <a
href="http://www.apache.org/foundation/faq.html">foundation FAQ</a>
explains the operation and background of the foundation.

Hadoop is typical of Apache projects in that it operates under a set
of principles, known collectively as the "Apache Way". If
you are new to Apache development, please refer to the <a
href="http://incubator.apache.org">Incubator project</a> for more
information on how Apache projects operate.

Roles and Responsibilities

Apache projects define a set of roles with associated rights and
responsibilities. These roles govern what tasks an individual may
perform within the project. The roles are defined in the following
sections

    * Users

         The most important participants in the project are people who
         use our software. The majority of our developers start out as
         users and guide their development efforts from the user's
         perspective.

        Users contribute to the Apache projects by providing feedback
         to developers in the form of bug reports and feature
         suggestions. As well, users participate in the Apache
         community by helping other users on mailing lists and user
         support forums.

    * Contributors

         All of the volunteers who are contributing time, code,
         documentation, or resources to the Hadoop Project. A  
contributor
         that makes sustained, welcome contributions to the project may
         be invited to become a Committer, though the exact timing of
         such invitations depends on many factors.

     * Committers

        The project's Committers are responsible for the project's
         technical management. Committers have access to a specified
         set of subprojects' subversion repositories. Committers on
         subprojects may cast binding votes on any technical discussion
         regarding that subproject.

        Committer access is by invitation only and must be approved by
         lazy consensus of the active PMC members. A Committer is
         considered emeritus by their own declaration or by not
         contributing in any form to the project for over six
         months. An emeritus committer may request reinstatement of
         commit access from the PMC. Such reinstatement is subject to
         lazy consensus of active PMC members.

       All Apache committers are required to have a signed Contributor
         License Agreement (CLA) on file with the Apache Software
         Foundation. There is a <a
         href="http://www.apache.org/dev/committers.html">Committer
         FAQ</a> which provides more details on the requirements for
         Committers

        A committer who makes a sustained contribution to the project
         may be invited to become a member of the PMC. The form of
         contribution is not limited to code. It can also include code
         review, helping out users on the mailing lists, documentation,
         testing, etc.

    * Project Management Committee

        The Project Management Committee (PMC) for Apache Hadoop was
         created by the Apache Board in January 2008 when Hadoop moved
         out of Lucene and became a top level project at Apache. The
         PMC is responsible to the board and the ASF for the management
         and oversight of the Apache Hadoop codebase. The
         responsibilities of the PMC include

        * Deciding what is distributed as products of the Apache Hadoop
         project.  In particular all releases must be approved by the
         PMC

         * Maintaining the project's shared resources, including the  
codebase
             repository, mailing lists, websites.

         * Speaking on behalf of the project.

        * Resolving license disputes regarding products of the project

         * Nominating new PMC members and committers

         * Maintaining these bylaws and other guidelines of the project

        Membership of the PMC is by invitation only and must be
         approved by a lazy consensus of active PMC members. A PMC
         member is considered "emeritus" by their own
         declaration or by not contributing in any form to the project
         for over six months. An emeritus member may request
         reinstatement to the PMC. Such reinstatement is subject to
         lazy consensus of the active PMC members.

        The chair of the PMC is appointed by the ASF board. The chair
         is an office holder of the Apache Software Foundation (Vice
         President, Apache Hadoop) and has primary responsibility to
         the board for the management of the projects within the scope
         of the Hadoop PMC. The chair reports to the board quarterly on
         developments within the Hadoop project.

When the current chair of the PMC resigns, the PMC votes to
recommend a new chair using lazy consensus, but the decision
must be ratified by the Apache board.

Decision Making

       Within the Hadoop project, different types of decisions require
       different forms of approval. For example, the <a href="#Roles
       and Responsibilities">previous section</a> describes several
       decisions which require "lazy consensus"
       approval. This section defines how voting is performed, the
       types of approvals, and which types of decision require which
       type of approval.

     * Voting

         Decisions regarding the project are made by votes on the
         primary project development mailing list
         (gene

Being a relatively new member of Hadoop community (just slightly over year
and a half) and never been exposed to its politics I can't help but to wonder
if such document didn't exist before?

If it did, then what's the difference between the current version and the
previous one? What's causing that change to be introduced?

If it didn't, then how Hadoop community has been governed beforehand?
By the general ASF rules or differently? If the rules were the same for ASF
and Hadoop why we need to deviate from them now and why?

Clearly, having written bylaws is handy in case of a dispute. However it'd be
great to know the history (or just a story) of this particular discussion.

Appreciate any information on the topic. Thanks in advance.
  Cos

On Tue, Oct 19, 2010 at 02:12PM, Owen O'Malley wrote:
> Apache Hadoop Project Bylaws
>
> This document defines the bylaws under which the Apache Hadoop project
> operates. It defines the roles and responsibilities of the project,
> who may vote, how voting works, how conflicts are resolved, etc.
>
> Hadoop is a project of the <a
> href="http://www.apache.org/foundation/">Apache Software
> Foundation</a>.  The foundation holds the trademark on the name
> "Hadoop" and copyright on Apache code
> including the code in the Hadoop codebase. The <a
> href="http://www.apache.org/foundation/faq.html">foundation FAQ</a>
> explains the operation and background of the foundation.
>
> Hadoop is typical of Apache projects in that it operates under a set
> of principles, known collectively as the "Apache Way". If
> you are new to Apache development, please refer to the <a
> href="http://incubator.apache.org">Incubator project</a> for more
> information on how Apache projects operate.
>
> Roles and Responsibilities
>
> Apache projects define a set of roles with associated rights and
> responsibilities. These roles govern what tasks an individual may
> perform within the project. The roles are defined in the following
> sections
>
>    * Users
>
>         The most important participants in the project are people who
>         use our software. The majority of our developers start out as
>         users and guide their development efforts from the user's
>         perspective.
>
>        Users contribute to the Apache projects by providing feedback
>         to developers in the form of bug reports and feature
>         suggestions. As well, users participate in the Apache
>         community by helping other users on mailing lists and user
>         support forums.
>
>    * Contributors
>
>         All of the volunteers who are contributing time, code,
>         documentation, or resources to the Hadoop Project. A
> contributor
>         that makes sustained, welcome contributions to the project may
>         be invited to become a Committer, though the exact timing of
>         such invitations depends on many factors.
>
>     * Committers
>
>        The project's Committers are responsible for the project's
>         technical management. Committers have access to a specified
>         set of subprojects' subversion repositories. Committers on
>         subprojects may cast binding votes on any technical discussion
>         regarding that subproject.
>
>        Committer access is by invitation only and must be approved by
>         lazy consensus of the active PMC members. A Committer is
>         considered emeritus by their own declaration or by not
>         contributing in any form to the project for over six
>         months. An emeritus committer may request reinstatement of
>         commit access from the PMC. Such reinstatement is subject to
>         lazy consensus of active PMC members.
>
>       All Apache committers are required to have a signed Contributor
>         License Agreement (CLA) on file with the Apache Software
>         Foundation. There is a <a
>         href="http://www.apache.org/dev/committers.html">Committer
>         FAQ</a> which provides more details on the requirements for

On Oct 19, 2010, at 2:35 PM, Konstantin Boudnik wrote:

> Being a relatively new member of Hadoop community (just slightly  
> over year
> and a half) and never been exposed to its politics I can't help but  
> to wonder
> if such document didn't exist before?

No, it should have been done when we form as a TLP, but it wasn't done.

-- Owen

Hey Cos,

There's some background in the proposal thread from last year.

http://mail-archives.apache.org/mod_mbox/hadoop-general/200911.mbox/%[EMAIL PROTECTED]%3E

Thanks,
Eli

On Tue, Oct 19, 2010 at 2:35 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> Being a relatively new member of Hadoop community (just slightly over year
> and a half) and never been exposed to its politics I can't help but to wonder
> if such document didn't exist before?
>
> If it did, then what's the difference between the current version and the
> previous one? What's causing that change to be introduced?
>
> If it didn't, then how Hadoop community has been governed beforehand?
> By the general ASF rules or differently? If the rules were the same for ASF
> and Hadoop why we need to deviate from them now and why?
>
> Clearly, having written bylaws is handy in case of a dispute. However it'd be
> great to know the history (or just a story) of this particular discussion.
>
> Appreciate any information on the topic. Thanks in advance.
>  Cos
>
> On Tue, Oct 19, 2010 at 02:12PM, Owen O'Malley wrote:
>> Apache Hadoop Project Bylaws
>>
>> This document defines the bylaws under which the Apache Hadoop project
>> operates. It defines the roles and responsibilities of the project,
>> who may vote, how voting works, how conflicts are resolved, etc.
>>
>> Hadoop is a project of the <a
>> href="http://www.apache.org/foundation/">Apache Software
>> Foundation</a>.  The foundation holds the trademark on the name
>> "Hadoop" and copyright on Apache code
>> including the code in the Hadoop codebase. The <a
>> href="http://www.apache.org/foundation/faq.html">foundation FAQ</a>
>> explains the operation and background of the foundation.
>>
>> Hadoop is typical of Apache projects in that it operates under a set
>> of principles, known collectively as the "Apache Way". If
>> you are new to Apache development, please refer to the <a
>> href="http://incubator.apache.org">Incubator project</a> for more
>> information on how Apache projects operate.
>>
>> Roles and Responsibilities
>>
>> Apache projects define a set of roles with associated rights and
>> responsibilities. These roles govern what tasks an individual may
>> perform within the project. The roles are defined in the following
>> sections
>>
>>    * Users
>>
>>         The most important participants in the project are people who
>>         use our software. The majority of our developers start out as
>>         users and guide their development efforts from the user's
>>         perspective.
>>
>>        Users contribute to the Apache projects by providing feedback
>>         to developers in the form of bug reports and feature
>>         suggestions. As well, users participate in the Apache
>>         community by helping other users on mailing lists and user
>>         support forums.
>>
>>    * Contributors
>>
>>         All of the volunteers who are contributing time, code,
>>         documentation, or resources to the Hadoop Project. A
>> contributor
>>         that makes sustained, welcome contributions to the project may
>>         be invited to become a Committer, though the exact timing of
>>         such invitations depends on many factors.
>>
>>     * Committers
>>
>>        The project's Committers are responsible for the project's
>>         technical management. Committers have access to a specified
>>         set of subprojects' subversion repositories. Committers on
>>         subprojects may cast binding votes on any technical discussion
>>         regarding that subproject.
>>
>>        Committer access is by invitation only and must be approved by
>>         lazy consensus of the active PMC members. A Committer is
>>         considered emeritus by their own declaration or by not
>>         contributing in any form to the project for over six
>>         months. An emeritus committer may request reinstatement of
>>         commit access from the PMC. Such reinstatement is subject to

On 10/19/2010 02:12 PM, Owen O'Malley wrote:
> * Committer Removal
>
> When removal of commit privileges is sought. Note: Such
> actions will also be referred to the ASF board by the PMC
> chair
>
> Majority of active PMC members (excluding the committer in question if a
> member of the PMC).
>
> * PMC Member Removal
>
> When removal of a PMC member is sought. Note: Such
> actions will also be referred to the ASF board by the PMC
> chair.
>
> Majority of active PMC members (excluding the member in question)

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?

Doug

On 19/10/10 22:12, Owen O'Malley wrote:
> Apache Hadoop Project Bylaws
>
> This document defines the bylaws under which the Apache Hadoop project
> operates. It defines the roles and responsibilities of the project,
> who may vote, how voting works, how conflicts are resolved, etc.
+1, looks like the standard ASF process

That said
  -the JIRA/hudson review process isn't so common on other projects,
where it's usually lazy post-commit-veto. That doesn't mean the Hadoop
process is bad, only that you may want to say "the process used for
getting code in is stricter than many existing ASF processes due to the
value of data stored in Hadoop clusters. The exact process for
committing code will be defined by the PMC and voted on" -then you can
propose/vote the existing process, but have the ability to change things
without reconstituting.

-the proposal for big changes that was discussed  may also be something
that this would cover

-Vetoes can kill a project. It's the situation you don't want to get,
where someone starts -1 rejecting everything. It might be good to lay
out what the escalation process is for resolving vetoes that cannot be
resolved -is there a way to raise with the PMC, etc.?

-steve

>
> Hadoop is a project of the <a
> href="http://www.apache.org/foundation/">Apache Software
> Foundation</a>. The foundation holds the trademark on the name
> "Hadoop" and copyright on Apache code
> including the code in the Hadoop codebase. The <a
> href="http://www.apache.org/foundation/faq.html">foundation FAQ</a>
> explains the operation and background of the foundation.
>
> Hadoop is typical of Apache projects in that it operates under a set
> of principles, known collectively as the "Apache Way". If
> you are new to Apache development, please refer to the <a
> href="http://incubator.apache.org">Incubator project</a> for more
> information on how Apache projects operate.
>
> Roles and Responsibilities
>
> Apache projects define a set of roles with associated rights and
> responsibilities. These roles govern what tasks an individual may
> perform within the project. The roles are defined in the following
> sections
>
> * Users
>
> The most important participants in the project are people who
> use our software. The majority of our developers start out as
> users and guide their development efforts from the user's
> perspective.
>
> Users contribute to the Apache projects by providing feedback
> to developers in the form of bug reports and feature
> suggestions. As well, users participate in the Apache
> community by helping other users on mailing lists and user
> support forums.
>
> * Contributors
>
> All of the volunteers who are contributing time, code,
> documentation, or resources to the Hadoop Project. A contributor
> that makes sustained, welcome contributions to the project may
> be invited to become a Committer, though the exact timing of
> such invitations depends on many factors.
>
> * Committers
>
> The project's Committers are responsible for the project's
> technical management. Committers have access to a specified
> set of subprojects' subversion repositories. Committers on
> subprojects may cast binding votes on any technical discussion
> regarding that subproject.
>
> Committer access is by invitation only and must be approved by
> lazy consensus of the active PMC members. A Committer is
> considered emeritus by their own declaration or by not
> contributing in any form to the project for over six
> months. An emeritus committer may request reinstatement of
> commit access from the PMC. Such reinstatement is subject to
> lazy consensus of active PMC members.
>
> All Apache committers are required to have a signed Contributor
> License Agreement (CLA) on file with the Apache Software
> Foundation. There is a <a
> href="http://www.apache.org/dev/committers.html">Committer
> FAQ</a> which provides more details on the requirements for
> Committers
>
> A committer who makes a sustained contribution to the project

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

On Oct 20, 2010, at 9:54 AM, Owen O'Malley 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.

FWIW, "PMC does not generally operate by majority but by consensus." was given as a rationale when explaining to an existing PMC member why it was ok to approve so many new PMC members from a single company.

Nige

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.

Cheers,
Tom

On Wed, Oct 20, 2010 at 9:54 AM, Owen O'Malley <[EMAIL PROTECTED]> 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

On Wed, Oct 20, 2010 at 10:14 AM, Nigel Daley <[EMAIL PROTECTED]> wrote:
> FWIW, "PMC does not generally operate by majority but by consensus." was given as a rationale when explaining to an existing PMC member why it was ok to approve so many new PMC members from a single company.

FWIW, working at the same company doesn't imbue contributors with a
shared agenda, neither does it rob them of their ability to
compromise, relieve their concern for the project's health, nor does
it diminish their respect for other contributors. If individuals from
that company display any of those traits, then the PMC should address
them. Equating association and collusion a priori is inadmissible. And
insulting.

On Wed, Oct 20, 2010 at 2:12 PM, Tom White <[EMAIL PROTECTED]> wrote:
> 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.

Consensus is equivalent to making the PMC a permanent appointment.
Discussions would be more civil and more likely to offer compromise-
we would actually work toward consensus- if intransigence and
hostility had consequences. Removing people is a last resort. Moving
the barrier closer doesn't make it more likely, but it aligns
incentives so rational people will reign in their more intemperate
comments and, instead, find ways to make progress.

Many projects require supermajorities or even 3/4 majorities. It's
sufficiently damning if more than half the PMC thinks an individual is
so destructive that less damage would be done by ejecting them, in my
opinion, but again: this is not a facility we should use, or have to
use. Throwing someone out is an expensive failure for the project, and
an conspicuous failure of its governance and community. Personally, I
don't care if it's a majority or a supermajority, but consensus is a
fig leaf.

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

IIRC, the reasoning for a full week in the last thread was to prevent
national holidays from affecting the definition of "working days." We
might expedite votes for security/patch releases. -C

On Wed, Oct 20, 2010 at 3:15 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 20, 2010 at 10:14 AM, Nigel Daley <[EMAIL PROTECTED]> wrote:
>> FWIW, "PMC does not generally operate by majority but by consensus." was given as a rationale when explaining to an existing PMC member why it was ok to approve so many new PMC members from a single company.
>
> FWIW, working at the same company doesn't imbue contributors with a
> shared agenda, neither does it rob them of their ability to
> compromise, relieve their concern for the project's health, nor does
> it diminish their respect for other contributors. If individuals from
> that company display any of those traits, then the PMC should address
> them. Equating association and collusion a priori is inadmissible. And
> insulting.
>
> On Wed, Oct 20, 2010 at 2:12 PM, Tom White <[EMAIL PROTECTED]> wrote:
>> 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.
>
> Consensus is equivalent to making the PMC a permanent appointment.
> Discussions would be more civil and more likely to offer compromise-
> we would actually work toward consensus- if intransigence and
> hostility had consequences. Removing people is a last resort. Moving
> the barrier closer doesn't make it more likely, but it aligns
> incentives so rational people will reign in their more intemperate
> comments and, instead, find ways to make progress.
>
> Many projects require supermajorities or even 3/4 majorities. It's
> sufficiently damning if more than half the PMC thinks an individual is
> so destructive that less damage would be done by ejecting them, in my
> opinion, but again: this is not a facility we should use, or have to
> use. Throwing someone out is an expensive failure for the project, and
> an conspicuous failure of its governance and community. Personally, I
> don't care if it's a majority or a supermajority, but consensus is a
> fig leaf.

Fair point. For a large PMC, that's probably true. This matter was
discussed on the Pig list, and there was a range of opinion there:
http://search-hadoop.com/m/jk35b2tZCuy&subj=RE+DISCUSS+Apache+Pig+bylaws.
Personally, I think a supermajority strikes the right balance.

Tom

>
>> Also, Pig has a minimum length of time for each action, rather than
>> the same fixed number for each. Might be worth considering.
>
> IIRC, the reasoning for a full week in the last thread was to prevent
> national holidays from affecting the definition of "working days." We
> might expedite votes for security/patch releases. -C
>

On Oct 21, 2010, at 10:10 AM, Tom White wrote:
> On Wed, Oct 20, 2010 at 3:15 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:

>>> 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.
>>
>> Consensus is equivalent to making the PMC a permanent appointment.
>> Discussions would be more civil and more likely to offer compromise-
>> we would actually work toward consensus- if intransigence and
>> hostility had consequences. Removing people is a last resort. Moving
>> the barrier closer doesn't make it more likely, but it aligns
>> incentives so rational people will reign in their more intemperate
>> comments and, instead, find ways to make progress.
>>
>> Many projects require supermajorities or even 3/4 majorities. It's
>> sufficiently damning if more than half the PMC thinks an individual is
>> so destructive that less damage would be done by ejecting them, in my
>> opinion, but again: this is not a facility we should use, or have to
>> use. Throwing someone out is an expensive failure for the project, and
>> an conspicuous failure of its governance and community. Personally, I
>> don't care if it's a majority or a supermajority, but consensus is a
>> fig leaf.
>
> Fair point. For a large PMC, that's probably true. This matter was
> discussed on the Pig list, and there was a range of opinion there:
> http://search-hadoop.com/m/jk35b2tZCuy&subj=RE+DISCUSS+Apache+Pig+bylaws.
> Personally, I think a supermajority strikes the right balance.
>
> Tom

Yup, all good points Chris. I, too, agree that supermajority strikes a good balance.

Nige

+1 on supermajority - enough "people democracy".

On Thu, Oct 21, 2010 at 11:39PM, Nigel Daley wrote:
>
> On Oct 21, 2010, at 10:10 AM, Tom White wrote:
> > On Wed, Oct 20, 2010 at 3:15 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
>
> >>> 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.
> >>
> >> Consensus is equivalent to making the PMC a permanent appointment.
> >> Discussions would be more civil and more likely to offer compromise-
> >> we would actually work toward consensus- if intransigence and
> >> hostility had consequences. Removing people is a last resort. Moving
> >> the barrier closer doesn't make it more likely, but it aligns
> >> incentives so rational people will reign in their more intemperate
> >> comments and, instead, find ways to make progress.
> >>
> >> Many projects require supermajorities or even 3/4 majorities. It's
> >> sufficiently damning if more than half the PMC thinks an individual is
> >> so destructive that less damage would be done by ejecting them, in my
> >> opinion, but again: this is not a facility we should use, or have to
> >> use. Throwing someone out is an expensive failure for the project, and
> >> an conspicuous failure of its governance and community. Personally, I
> >> don't care if it's a majority or a supermajority, but consensus is a
> >> fig leaf.
> >
> > Fair point. For a large PMC, that's probably true. This matter was
> > discussed on the Pig list, and there was a range of opinion there:
> > http://search-hadoop.com/m/jk35b2tZCuy&subj=RE+DISCUSS+Apache+Pig+bylaws.
> > Personally, I think a supermajority strikes the right balance.
> >
> > Tom
>
> Yup, all good points Chris. I, too, agree that supermajority strikes a good balance.
>
> Nige