You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@hadoop.apache.org by Owen O'Malley <om...@apache.org> on 2010/10/19 23:12:52 UTC
[DISCUSS] Proposed bylaws for Hadoop
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
(general@hadoop.apache.org). Where necessary, PMC voting may
take place on the private Hadoop PMC mailing list. Votes are
clearly indicated by subject line starting with [VOTE]. Votes
may contain multiple items for approval and these should be
clearly separated. Voting is carried out by replying to the
vote mail. Voting may take four flavours
* +1 "Yes," "Agree," or "the action
should be
performed." In general, this vote also indicates a
willingness
on the behalf of the voter in "making it happen"
* +0 This vote indicates a willingness for the action under
consideration to go ahead. The voter, however will not be
able
to help.
* -0 This vote indicates that the voter does not, in
general, agree with
the proposed action but is not concerned enough to
prevent the
action going ahead.
* -1 This is a negative vote. On issues where consensus is
required,
this vote counts as a <strong>veto</strong>. All vetoes
must
contain an explanation of why the veto is appropriate.
Vetoes with
no explanation are void. It may also be appropriate for a
-1 vote
to include an alternative course of action.
All participants in the Hadoop project are encouraged to show
their
agreement with or against a particular action by voting. For
technical
decisions, only the votes of active committers are binding.
Non binding
votes are still useful for those with binding votes to
understand the
perception of an action in the wider Hadoop community. For
PMC decisions,
only the votes of PMC members are binding.
Voting can also be applied to changes made to the Hadoop
codebase. These
typically take the form of a veto (-1) in reply to the commit
message
sent when the commit is made.
* Approvals
These are the types of approvals that can be sought.
Different actions
require different types of approvals
* Lazy Consensus - Lazy consensus requires 3 binding +1 votes
and no binding vetoes.
* Lazy Majority - A lazy majority vote requires 3 binding +1
votes and more binding +1 votes than -1 votes.
* Lazy 2/3 Majority - Lazy 2/3 majority votes requires at
least 3 votes and twice as many +1 votes as -1 votes.
* Vetoes
A valid, binding veto cannot be overruled. If a veto is cast,
it must be accompanied by a valid reason explaining the
reasons for the veto. The validity of a veto, if challenged,
can be confirmed by anyone who has a binding vote. This does
not necessarily signify agreement with the veto - merely that
the veto is valid.
If you disagree with a valid veto, you must lobby the person
casting
the veto to withdraw their veto. If a veto is not withdrawn,
any action
that has been vetoed must be reversed in a timely manner.
* Actions
This section describes the various actions which are
undertaken within
the project, the corresponding approval required for that
action and
those who have binding votes over the action.
* Code Change
A change made to a codebase of the project and committed
by a committer. This includes source code, documentation,
website
content, etc.
Lazy consensus of active committers.
* Release Plan
Defines the timetable and actions for a release. The plan
also
nominates a Release Manager.
Lazy majority of active committers
* Product Release
When a release of one of the project's products is ready,
a vote is
required to accept the release as an official release of
the
project.
Lazy Majority of active PMC members
* Adoption of New Codebase
When the codebase for an existing, released product is to
be
replaced with an alternative codebase. If such a vote
fails to
gain approval, the existing code base will continue.
This also covers the creation of new sub-projects
within the project
Lazy 2/3 majority of PMC members
* New Committer
When a new committer is proposed for the project
Lazy consensus of active PMC members
* New PMC Member
When a committer is proposed for the PMC
Lazy consensus of active PMC members
* 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)
* Modifying Bylaws
Modifying this document.
Majority of active PMC members
* Voting Timeframes
Votes are open for a period of 7 days to allow all active
voters time to consider the vote. Votes relating to code
changes are not subject to a strict timetable but should be
made as timely as possible.
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Tom White <to...@gmail.com>.
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 <om...@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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Konstantin Boudnik <co...@apache.org>.
+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 <cd...@apache.org> 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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Nigel Daley <nd...@mac.com>.
On Oct 21, 2010, at 10:10 AM, Tom White wrote:
> On Wed, Oct 20, 2010 at 3:15 PM, Chris Douglas <cd...@apache.org> 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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Tom White <to...@gmail.com>.
On Wed, Oct 20, 2010 at 3:15 PM, Chris Douglas <cd...@apache.org> wrote:
> On Wed, Oct 20, 2010 at 10:14 AM, Nigel Daley <nd...@mac.com> 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 <to...@gmail.com> 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
>
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Chris Douglas <cd...@apache.org>.
On Wed, Oct 20, 2010 at 10:14 AM, Nigel Daley <nd...@mac.com> 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 <to...@gmail.com> 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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Nigel Daley <nd...@mac.com>.
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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Owen O'Malley <om...@apache.org>.
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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Doug Cutting <cu...@apache.org>.
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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Steve Loughran <st...@apache.org>.
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
> 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
> (general@hadoop.apache.org). Where necessary, PMC voting may
> take place on the private Hadoop PMC mailing list. Votes are
> clearly indicated by subject line starting with [VOTE]. Votes
> may contain multiple items for approval and these should be
> clearly separated. Voting is carried out by replying to the
> vote mail. Voting may take four flavours
>
> * +1 "Yes," "Agree," or "the action should be
> performed." In general, this vote also indicates a willingness
> on the behalf of the voter in "making it happen"
>
> * +0 This vote indicates a willingness for the action under
> consideration to go ahead. The voter, however will not be able
> to help.
>
> * -0 This vote indicates that the voter does not, in general, agree with
> the proposed action but is not concerned enough to prevent the
> action going ahead.
>
> * -1 This is a negative vote. On issues where consensus is required,
> this vote counts as a <strong>veto</strong>. All vetoes must
> contain an explanation of why the veto is appropriate. Vetoes with
> no explanation are void. It may also be appropriate for a -1 vote
> to include an alternative course of action.
>
> All participants in the Hadoop project are encouraged to show their
> agreement with or against a particular action by voting. For technical
> decisions, only the votes of active committers are binding. Non binding
> votes are still useful for those with binding votes to understand the
> perception of an action in the wider Hadoop community. For PMC decisions,
> only the votes of PMC members are binding.
>
> Voting can also be applied to changes made to the Hadoop codebase. These
> typically take the form of a veto (-1) in reply to the commit message
> sent when the commit is made.
>
> * Approvals
>
> These are the types of approvals that can be sought. Different actions
> require different types of approvals
>
> * Lazy Consensus - Lazy consensus requires 3 binding +1 votes
> and no binding vetoes.
>
> * Lazy Majority - A lazy majority vote requires 3 binding +1
> votes and more binding +1 votes than -1 votes.
>
> * Lazy 2/3 Majority - Lazy 2/3 majority votes requires at
> least 3 votes and twice as many +1 votes as -1 votes.
>
> * Vetoes
>
> A valid, binding veto cannot be overruled. If a veto is cast,
> it must be accompanied by a valid reason explaining the
> reasons for the veto. The validity of a veto, if challenged,
> can be confirmed by anyone who has a binding vote. This does
> not necessarily signify agreement with the veto - merely that
> the veto is valid.
>
> If you disagree with a valid veto, you must lobby the person casting
> the veto to withdraw their veto. If a veto is not withdrawn, any action
> that has been vetoed must be reversed in a timely manner.
>
> * Actions
>
> This section describes the various actions which are undertaken within
> the project, the corresponding approval required for that action and
> those who have binding votes over the action.
>
> * Code Change
>
> A change made to a codebase of the project and committed
> by a committer. This includes source code, documentation, website
> content, etc.
>
> Lazy consensus of active committers.
>
> * Release Plan
>
> Defines the timetable and actions for a release. The plan also
> nominates a Release Manager.
>
> Lazy majority of active committers
>
> * Product Release
>
> When a release of one of the project's products is ready, a vote is
> required to accept the release as an official release of the
> project.
>
> Lazy Majority of active PMC members
>
> * Adoption of New Codebase
>
> When the codebase for an existing, released product is to be
> replaced with an alternative codebase. If such a vote fails to
> gain approval, the existing code base will continue.
>
> This also covers the creation of new sub-projects
> within the project
>
> Lazy 2/3 majority of PMC members
>
> * New Committer
>
> When a new committer is proposed for the project
>
> Lazy consensus of active PMC members
>
> * New PMC Member
>
> When a committer is proposed for the PMC
>
> Lazy consensus of active PMC members
>
> * 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)
>
> * Modifying Bylaws
>
> Modifying this document.
>
> Majority of active PMC members
>
> * Voting Timeframes
>
> Votes are open for a period of 7 days to allow all active
> voters time to consider the vote. Votes relating to code
> changes are not subject to a strict timetable but should be
> made as timely as possible.
>
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Owen O'Malley <om...@apache.org>.
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
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Eli Collins <el...@cloudera.com>.
Hey Cos,
There's some background in the proposal thread from last year.
http://mail-archives.apache.org/mod_mbox/hadoop-general/200911.mbox/%3C284E0999-F935-47A2-B051-7241BF8A4B39@apache.org%3E
Thanks,
Eli
On Tue, Oct 19, 2010 at 2:35 PM, Konstantin Boudnik <co...@apache.org> 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
>> 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
>> (general@hadoop.apache.org). Where necessary, PMC voting may
>> take place on the private Hadoop PMC mailing list. Votes are
>> clearly indicated by subject line starting with [VOTE]. Votes
>> may contain multiple items for approval and these should be
>> clearly separated. Voting is carried out by replying to the
>> vote mail. Voting may take four flavours
>>
>> * +1 "Yes," "Agree," or "the action
>> should be
>> performed." In general, this vote also indicates a
>> willingness
>> on the behalf of the voter in "making it happen"
>>
>> * +0 This vote indicates a willingness for the action under
>> consideration to go ahead. The voter, however will not
>> be able
>> to help.
>>
>> * -0 This vote indicates that the voter does not, in
>> general, agree with
>> the proposed action but is not concerned enough to
>> prevent the
>> action going ahead.
>>
>> * -1 This is a negative vote. On issues where consensus is
>> required,
>> this vote counts as a <strong>veto</strong>. All vetoes
>> must
>> contain an explanation of why the veto is appropriate.
>> Vetoes with
>> no explanation are void. It may also be appropriate for
>> a -1 vote
>> to include an alternative course of action.
>>
>> All participants in the Hadoop project are encouraged to
>> show their
>> agreement with or against a particular action by voting. For
>> technical
>> decisions, only the votes of active committers are binding.
>> Non binding
>> votes are still useful for those with binding votes to
>> understand the
>> perception of an action in the wider Hadoop community. For
>> PMC decisions,
>> only the votes of PMC members are binding.
>>
>> Voting can also be applied to changes made to the Hadoop
>> codebase. These
>> typically take the form of a veto (-1) in reply to the
>> commit message
>> sent when the commit is made.
>>
>> * Approvals
>>
>> These are the types of approvals that can be sought.
>> Different actions
>> require different types of approvals
>>
>> * Lazy Consensus - Lazy consensus requires 3 binding +1 votes
>> and no binding vetoes.
>>
>> * Lazy Majority - A lazy majority vote requires 3 binding +1
>> votes and more binding +1 votes than -1 votes.
>>
>> * Lazy 2/3 Majority - Lazy 2/3 majority votes requires at
>> least 3 votes and twice as many +1 votes as -1 votes.
>>
>> * Vetoes
>>
>> A valid, binding veto cannot be overruled. If a veto is cast,
>> it must be accompanied by a valid reason explaining the
>> reasons for the veto. The validity of a veto, if challenged,
>> can be confirmed by anyone who has a binding vote. This does
>> not necessarily signify agreement with the veto - merely that
>> the veto is valid.
>>
>> If you disagree with a valid veto, you must lobby the person
>> casting
>> the veto to withdraw their veto. If a veto is not withdrawn,
>> any action
>> that has been vetoed must be reversed in a timely manner.
>>
>> * Actions
>>
>> This section describes the various actions which are
>> undertaken within
>> the project, the corresponding approval required for that
>> action and
>> those who have binding votes over the action.
>>
>> * Code Change
>>
>> A change made to a codebase of the project and committed
>> by a committer. This includes source code,
>> documentation, website
>> content, etc.
>>
>> Lazy consensus of active committers.
>>
>> * Release Plan
>>
>> Defines the timetable and actions for a release. The
>> plan also
>> nominates a Release Manager.
>>
>> Lazy majority of active committers
>>
>> * Product Release
>>
>> When a release of one of the project's products is
>> ready, a vote is
>> required to accept the release as an official release of
>> the
>> project.
>>
>> Lazy Majority of active PMC members
>>
>> * Adoption of New Codebase
>>
>> When the codebase for an existing, released product is
>> to be
>> replaced with an alternative codebase. If such a vote
>> fails to
>> gain approval, the existing code base will continue.
>>
>> This also covers the creation of new sub-projects
>> within the project
>>
>> Lazy 2/3 majority of PMC members
>>
>> * New Committer
>>
>> When a new committer is proposed for the project
>>
>> Lazy consensus of active PMC members
>>
>> * New PMC Member
>>
>> When a committer is proposed for the PMC
>>
>> Lazy consensus of active PMC members
>>
>> * 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)
>>
>> * Modifying Bylaws
>>
>> Modifying this document.
>>
>> Majority of active PMC members
>>
>> * Voting Timeframes
>>
>> Votes are open for a period of 7 days to allow all active
>> voters time to consider the vote. Votes relating to code
>> changes are not subject to a strict timetable but should be
>> made as timely as possible.
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAky+DycACgkQIg9pgB8n5iKiqgCfSj59WPJe/GZ9PIEcCbMBOf15
> N1kAn3+cXTvwAIpVIznExdfo2YlJg+uU
> =Vu5R
> -----END PGP SIGNATURE-----
>
>
Re: [DISCUSS] Proposed bylaws for Hadoop
Posted by Konstantin Boudnik <co...@apache.org>.
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
> 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
> (general@hadoop.apache.org). Where necessary, PMC voting may
> take place on the private Hadoop PMC mailing list. Votes are
> clearly indicated by subject line starting with [VOTE]. Votes
> may contain multiple items for approval and these should be
> clearly separated. Voting is carried out by replying to the
> vote mail. Voting may take four flavours
>
> * +1 "Yes," "Agree," or "the action
> should be
> performed." In general, this vote also indicates a
> willingness
> on the behalf of the voter in "making it happen"
>
> * +0 This vote indicates a willingness for the action under
> consideration to go ahead. The voter, however will not
> be able
> to help.
>
> * -0 This vote indicates that the voter does not, in
> general, agree with
> the proposed action but is not concerned enough to
> prevent the
> action going ahead.
>
> * -1 This is a negative vote. On issues where consensus is
> required,
> this vote counts as a <strong>veto</strong>. All vetoes
> must
> contain an explanation of why the veto is appropriate.
> Vetoes with
> no explanation are void. It may also be appropriate for
> a -1 vote
> to include an alternative course of action.
>
> All participants in the Hadoop project are encouraged to
> show their
> agreement with or against a particular action by voting. For
> technical
> decisions, only the votes of active committers are binding.
> Non binding
> votes are still useful for those with binding votes to
> understand the
> perception of an action in the wider Hadoop community. For
> PMC decisions,
> only the votes of PMC members are binding.
>
> Voting can also be applied to changes made to the Hadoop
> codebase. These
> typically take the form of a veto (-1) in reply to the
> commit message
> sent when the commit is made.
>
> * Approvals
>
> These are the types of approvals that can be sought.
> Different actions
> require different types of approvals
>
> * Lazy Consensus - Lazy consensus requires 3 binding +1 votes
> and no binding vetoes.
>
> * Lazy Majority - A lazy majority vote requires 3 binding +1
> votes and more binding +1 votes than -1 votes.
>
> * Lazy 2/3 Majority - Lazy 2/3 majority votes requires at
> least 3 votes and twice as many +1 votes as -1 votes.
>
> * Vetoes
>
> A valid, binding veto cannot be overruled. If a veto is cast,
> it must be accompanied by a valid reason explaining the
> reasons for the veto. The validity of a veto, if challenged,
> can be confirmed by anyone who has a binding vote. This does
> not necessarily signify agreement with the veto - merely that
> the veto is valid.
>
> If you disagree with a valid veto, you must lobby the person
> casting
> the veto to withdraw their veto. If a veto is not withdrawn,
> any action
> that has been vetoed must be reversed in a timely manner.
>
> * Actions
>
> This section describes the various actions which are
> undertaken within
> the project, the corresponding approval required for that
> action and
> those who have binding votes over the action.
>
> * Code Change
>
> A change made to a codebase of the project and committed
> by a committer. This includes source code,
> documentation, website
> content, etc.
>
> Lazy consensus of active committers.
>
> * Release Plan
>
> Defines the timetable and actions for a release. The
> plan also
> nominates a Release Manager.
>
> Lazy majority of active committers
>
> * Product Release
>
> When a release of one of the project's products is
> ready, a vote is
> required to accept the release as an official release of
> the
> project.
>
> Lazy Majority of active PMC members
>
> * Adoption of New Codebase
>
> When the codebase for an existing, released product is
> to be
> replaced with an alternative codebase. If such a vote
> fails to
> gain approval, the existing code base will continue.
>
> This also covers the creation of new sub-projects
> within the project
>
> Lazy 2/3 majority of PMC members
>
> * New Committer
>
> When a new committer is proposed for the project
>
> Lazy consensus of active PMC members
>
> * New PMC Member
>
> When a committer is proposed for the PMC
>
> Lazy consensus of active PMC members
>
> * 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)
>
> * Modifying Bylaws
>
> Modifying this document.
>
> Majority of active PMC members
>
> * Voting Timeframes
>
> Votes are open for a period of 7 days to allow all active
> voters time to consider the vote. Votes relating to code
> changes are not subject to a strict timetable but should be
> made as timely as possible.
>