hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen O'Malley <omal...@apache.org>
Subject [VOTE] Hadoop Bylaws
Date Sat, 20 Nov 2010 06:45:04 GMT
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.


Mime
View raw message