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.
