hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: [VOTE] Hadoop Bylaws
Date Mon, 22 Nov 2010 18:27:33 GMT
+1 -C


Summary of protocol for major votes:
  Adding code: Lazy consensus (committers)
  Release plan: Lazy majority (committers)
  Releasing code: Lazy majority (PMC)
  New codebase/subproject: Lazy 2/3 majority (PMC)
  Adding contributor: Lazy consensus (PMC)
  Removing contributor: Lazy 2/3 majority (PMC)
  Change bylaws: Majority (PMC)
  7 day voting period

On Fri, Nov 19, 2010 at 10:45 PM, Owen O'Malley <omalley@apache.org> 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
>            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.

View raw message