Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <E5F77221-9320-4251-9F15-2119F7435670@yahoo-inc.com>
From: Arun C Murthy <acm@yahoo-inc.com>
To: "general@hadoop.apache.org" <general@hadoop.apache.org>
In-Reply-To: <270521A0-A54F-4482-8A36-ABD6FB5ECD96@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [VOTE] Hadoop Bylaws
Date: Mon, 22 Nov 2010 10:32:51 -0800
References: <270521A0-A54F-4482-8A36-ABD6FB5ECD96@apache.org>

+1, especially given the modifications to incorporate 2/3 Lazy  
Consensus for removals.

Arun

On Nov 19, 2010, at 10:45 PM, Owen O'Malley wrote:

> All,
>    I've updated the proposed bylaws that I sent out a few weeks ago
> as suggested by making the vote for removal be a lazy 2/3, so now all
> of the votes are lazy. As before, by a recursive application of the
> bylaws let's let the vote last 7 days (11/26) and require a lazy
> majority of PMC members to pass.
>
> -- Owen
>
> 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 &quot;Apache Way&quot;. 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 &quot;emeritus&quot; 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 &quot;lazy consensus&quot;
>       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 flavors
>
>         * +1 &quot;Yes,&quot; &quot;Agree,&quot; or &quot;the action
> should be
>             performed.&quot; In general, this vote also indicates a
> willingness
>             on the behalf of the voter in &quot;making it happen&quot;
>
>          * +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
>
>             Lazy 2/3 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.
>
>             Lazy 2/3 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.
>