hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [DISCUSS] Proposed bylaws for Hadoop
Date Tue, 19 Oct 2010 21:46:27 GMT
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 <cos@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 &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 flavours
>>
>>         * +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
>>
>>             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-----
>
>

Mime
View raw message