Repository: incubator-impala Updated Branches: refs/heads/asf-site dd98199ad -> 90a4ea0de
Update bylaws: Lazy Consensus for branch creation and deletion. While I'm here, fix a formatting question and remove link to Hadoop's "How to Release" page (we don't have one yet). By the current bylaws, this change requires lazy majority (3 binding +1 votes and more binding +1 votes than -1 votes) from PMC members before it can be committed. Change-Id: I0097204f8d43ef20ceea6e3f37efcad9f12123f8 Reviewed-on: http://gerrit.cloudera.org:8080/4053 Reviewed-by: Jim Apple <[email protected]> Tested-by: Jim Apple <[email protected]> Project: http://git-wip-us.apache.org/repos/asf/incubator-impala/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-impala/commit/90a4ea0d Tree: http://git-wip-us.apache.org/repos/asf/incubator-impala/tree/90a4ea0d Diff: http://git-wip-us.apache.org/repos/asf/incubator-impala/diff/90a4ea0d Branch: refs/heads/asf-site Commit: 90a4ea0def699381a67615939c7e092479ab9671 Parents: dd98199 Author: Jim Apple <[email protected]> Authored: Thu Aug 18 15:55:22 2016 -0700 Committer: Jim Apple <[email protected]> Committed: Mon Aug 29 03:14:22 2016 +0000 ---------------------------------------------------------------------- bylaws.html | 591 ++++++++++++++++++++++++++++--------------------------- 1 file changed, 303 insertions(+), 288 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-impala/blob/90a4ea0d/bylaws.html ---------------------------------------------------------------------- diff --git a/bylaws.html b/bylaws.html index 07a5990..28651ea 100644 --- a/bylaws.html +++ b/bylaws.html @@ -15,7 +15,7 @@ <!-- Le styles --> <link href="css/bootstrap.css" rel="stylesheet" type="text/css"> <style type="text/css"> - body { +body { padding-top: 20px; padding-bottom: 40px; } @@ -146,340 +146,355 @@ |start content +--> - <div id="content"> - <h1>Apache Impala (incubating) Project Bylaws</h1><a name="N1000D"></a><a name= - "Introduction"></a> - - <h2 class="h3">Introduction</h2> - - <div class="section"> - <p>This document defines the bylaws under which the Apache Impala (incubating) - project operates. It defines the roles and responsibilities of the project, who may - vote, how voting works, how conflicts are resolved, etc.</p> - - <p>Impala is a project of the <a href="http://www.apache.org/foundation/";>Apache - Software Foundation</a>. The foundation holds the trademark on the name "Impala" - and copyright on Apache code including the code in the Impala codebase. The - <a href="http://www.apache.org/foundation/faq.html";>foundation FAQ</a> explains the - operation and background of the foundation.</p> - - <p>Impala 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.</p> - </div><a name="N10028"></a><a name="Roles+and+Responsibilities"></a> - - <h2 class="h3">Roles and Responsibilities</h2> - - <div class="section"> - <p>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</p> - - <ul> - <li> - <strong>Users</strong> - - <p>The most important participants in the project are people who use our - software.</p> - - <p>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.</p> - </li> - - <li> - <strong>Contributors</strong> - - <p>All of the volunteers who are contributing time, code, documentation, or - resources to the Impala 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.</p> - </li> - - <li> - <strong>Committers</strong> - - <p>The project's Committers are responsible for the project's technical - management. Committers have write access to the project's version control - repositories. Committers may cast binding votes on any technical - discussion.</p> - - <p>Committer access is by invitation only and must be approved by consensus - approval 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 consensus approval of active PMC - members.</p> - - <p>Significant, pervasive features may be developed in a speculative branch of - the repository. The PMC may grant commit rights on the branch to its consistent - contributors for the duration of the initiative. Branch committers are - responsible for shepherding their feature into an active release and do not - cast binding votes or vetoes in the project.</p> - - <p>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</p> - - <p>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.</p> - </li> - - <li> - <strong>Release Manager</strong> - - <p>A Release Manager (RM) is a committer who volunteers to produce a Release - Candidate according to <a href= - "https://wiki.apache.org/hadoop/HowToRelease";>HowToRelease</a>. The RM shall - publish a Release Plan on the <em>dev@</em> list stating the branch from which - they intend to make a Release Candidate, at least one week before they do so. - The RM is responsible for building consensus around the content of the Release - Candidate, in order to achieve a successful Product Release vote.</p> - </li> - - <li> - <strong>Project Management Committee</strong> - - <p>The Project Management Committee (PMC) is responsible to the board and the - ASF for the management and oversight of the Apache Impala codebase. The - responsibilities of the PMC include</p> - - <ul> - <li>Deciding what is distributed as products of the Apache Impala project. In - particular all releases must be approved by the PMC</li> - - <li>Maintaining the project's shared resources, including the codebase - repository, mailing lists, and websites.</li> - - <li>Speaking on behalf of the project.</li> - - <li>Resolving license disputes regarding products of the project</li> - - <li>Nominating new PMC members and committers</li> - - <li>Maintaining these bylaws and other guidelines of the project</li> - </ul> - - <p>Membership of the PMC is by invitation only and must be approved by a - consensus approval 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 consensus approval of the active PMC members.</p> - - <p>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 Impala) and - has primary responsibility to the board for the management of the projects - within the scope of the Impala PMC. The chair reports to the board quarterly on - developments within the Impala project.</p> - - <p>The chair of the PMC is rotated annually. When the chair is rotated or if - the current chair of the PMC resigns, the PMC votes to recommend a new chair - using Single Transferable Vote (STV) voting. See <a href= - "http://wiki.apache.org/general/BoardVoting";>BoardVoting</a> for specifics. The - decision must be ratified by the Apache board.</p> - </li> - </ul> - </div><a name="N10094"></a><a name="Decision+Making"></a> - - <h2 class="h3">Decision Making</h2> - - <div class="section"> - <p>Within the Impala 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 "consensus approval" - approval. This section defines how voting is performed, the types of approvals, and - which types of decision require which type of approval.</p> - - <ul> - <li> - <strong>Voting</strong> - - <p>Decisions regarding the project are made by votes on the primary project - development mailing list ([email protected]). Where necessary, PMC - voting may take place on the private Impala 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</p> - - <ul> - <li><strong>+1</strong> "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"</li> - - <li><strong>+0</strong> This vote indicates a willingness for the action - under consideration to go ahead. The voter, however will not be able to - help.</li> - - <li><strong>-0</strong> 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.</li> + <div class="row-fluid"> + <div class="span12"> + <h1>Apache Impala (incubating) Project Bylaws</h1><a name="N1000D"></a><a name= + "Introduction"></a> + + <h2 class="h3">Introduction</h2> + + <div class="section"> + <p>This document defines the bylaws under which the Apache Impala (incubating) + project operates. It defines the roles and responsibilities of the project, who + may vote, how voting works, how conflicts are resolved, etc.</p> + + <p>Impala is a project of the <a href="http://www.apache.org/foundation/";>Apache + Software Foundation</a>. The foundation holds the trademark on the name "Impala" + and copyright on Apache code including the code in the Impala codebase. The + <a href="http://www.apache.org/foundation/faq.html";>foundation FAQ</a> explains + the operation and background of the foundation.</p> + + <p>Impala 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.</p> + </div><a name="N10028"></a><a name="Roles+and+Responsibilities"></a> + + <h2 class="h3">Roles and Responsibilities</h2> + + <div class="section"> + <p>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</p> + + <ul> + <li> + <strong>Users</strong> + + <p>The most important participants in the project are people who use our + software.</p> + + <p>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.</p> + </li> + + <li> + <strong>Contributors</strong> + + <p>All of the volunteers who are contributing time, code, documentation, or + resources to the Impala 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.</p> + </li> + + <li> + <strong>Committers</strong> + + <p>The project's Committers are responsible for the project's technical + management. Committers have write access to the project's version control + repositories. Committers may cast binding votes on any technical + discussion.</p> + + <p>Committer access is by invitation only and must be approved by consensus + approval 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 consensus approval of + active PMC members.</p> + + <p>Significant, pervasive features may be developed in a speculative branch + of the repository. The PMC may grant commit rights on the branch to its + consistent contributors for the duration of the initiative. Branch committers + are responsible for shepherding their feature into an active release and do + not cast binding votes or vetoes in the project.</p> + + <p>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</p> + + <p>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.</p> + </li> + + <li> + <strong>Release Manager</strong> + + <p>A Release Manager (RM) is a committer who volunteers to produce a Release + Candidate. The RM shall publish a Release Plan on the <em>dev@</em> list + stating the branch from which they intend to make a Release Candidate, at + least one week before they do so. The RM is responsible for building + consensus around the content of the Release Candidate, in order to achieve a + successful Product Release vote.</p> + </li> + + <li> + <strong>Project Management Committee</strong> + + <p>The Project Management Committee (PMC) is responsible to the board and the + ASF for the management and oversight of the Apache Impala codebase. The + responsibilities of the PMC include</p> + + <ul> + <li>Deciding what is distributed as products of the Apache Impala project. + In particular all releases must be approved by the PMC</li> + + <li>Maintaining the project's shared resources, including the codebase + repository, mailing lists, and websites.</li> + + <li>Speaking on behalf of the project.</li> + + <li>Resolving license disputes regarding products of the project</li> + + <li>Nominating new PMC members and committers</li> + + <li>Maintaining these bylaws and other guidelines of the project</li> + </ul> - <li><strong>-1</strong> 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.</li> - </ul> + <p>Membership of the PMC is by invitation only and must be approved by a + consensus approval 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 consensus approval of the active + PMC members.</p> + + <p>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 Impala) and + has primary responsibility to the board for the management of the projects + within the scope of the Impala PMC. The chair reports to the board quarterly + on developments within the Impala project.</p> + + <p>The chair of the PMC is rotated annually. When the chair is rotated or if + the current chair of the PMC resigns, the PMC votes to recommend a new chair + using Single Transferable Vote (STV) voting. See <a href= + "http://wiki.apache.org/general/BoardVoting";>BoardVoting</a> for specifics. + The decision must be ratified by the Apache board.</p> + </li> + </ul> + </div><a name="N10094"></a><a name="Decision+Making"></a> + + <h2 class="h3">Decision Making</h2> + + <div class="section"> + <p>Within the Impala 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 "consensus approval" approval. This section defines how voting is + performed, the types of approvals, and which types of decision require which type + of approval.</p> + + <ul> + <li> + <strong>Voting</strong> + + <p>Decisions regarding the project are made by votes on the primary project + development mailing list ([email protected]). Where necessary, + PMC voting may take place on the private Impala 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</p> + + <ul> + <li><strong>+1</strong> "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"</li> + + <li><strong>+0</strong> This vote indicates a willingness for the action + under consideration to go ahead. The voter, however will not be able to + help.</li> + + <li><strong>-0</strong> 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.</li> + + <li><strong>-1</strong> 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.</li> + </ul> - <p>Patches are reviewed in the code review tool, where the vote flavors are:</p> + <p>Patches are reviewed in the code review tool, where the vote flavors + are:</p> - <ul> - <li><strong>+2</strong> "I am confident in the change and this can be - committed without further review after addressing the remaining points I have - made."</li> + <ul> + <li><strong>+2</strong> "I am confident in the change and this can be + committed without further review after addressing the remaining points I + have made."</li> - <li><strong>+1</strong> "I am OK with this being committed after the remaining - points in my comment have been addressed and someone else votes +2."</li> + <li><strong>+1</strong> "I am OK with this being committed after the + remaining points in my comment have been addressed and someone else votes + +2."</li> - <li><strong>-1</strong> "I oppose this being committed."</li> - </ul> + <li><strong>-1</strong> "I oppose this being committed."</li> + </ul> - <p>All participants in the Impala 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 Impala community. For PMC decisions, only the votes of - PMC members are binding.</p> - </li> + <p>All participants in the Impala 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 Impala community. For PMC decisions, only the votes of + PMC members are binding.</p> + </li> - <li> - <strong>Approvals</strong> + <li> + <strong>Approvals</strong> - <p>These are the types of approvals that can be sought. Different actions - require different types of approvals</p> + <p>These are the types of approvals that can be sought. Different actions + require different types of approvals</p> - <ul> - <li><strong>Consensus Approval -</strong> Consensus approval requires 3 - binding +1 votes and no binding vetoes.</li> + <ul> + <li><strong>Consensus Approval -</strong> Consensus approval requires 3 + binding +1 votes and no binding vetoes.</li> - <li><strong>Lazy Consensus -</strong> Lazy consensus requires no -1 votes - ('silence gives assent').</li> + <li><strong>Lazy Consensus -</strong> Lazy consensus requires no -1 votes + ('silence gives assent').</li> - <li><strong>Lazy Majority -</strong> A lazy majority vote requires 3 binding - +1 votes and more binding +1 votes than -1 votes.</li> + <li><strong>Lazy Majority -</strong> A lazy majority vote requires 3 + binding +1 votes and more binding +1 votes than -1 votes.</li> - <li><strong>Lazy 2/3 Majority -</strong> Lazy 2/3 majority votes requires at - least 3 votes and twice as many +1 votes as -1 votes.</li> - </ul> - </li> + <li><strong>Lazy 2/3 Majority -</strong> Lazy 2/3 majority votes requires + at least 3 votes and twice as many +1 votes as -1 votes.</li> + </ul> + </li> - <li> - <strong>Vetoes</strong> + <li> + <strong>Vetoes</strong> - <p>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.</p> + <p>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.</p> - <p>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.</p> - </li> + <p>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.</p> + </li> - <li> - <strong>Actions</strong> + <li> + <strong>Actions</strong> - <p>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.</p> + <p>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.</p> - <ul> - <li> - <strong>Code Change</strong> + <ul> + <li> + <strong>Code Change</strong> - <p>A change made to a codebase of the project and committed by a committer. - This includes source code, documentation, website content, etc.</p> + <p>A change made to a codebase of the project and committed by a + committer. This includes source code, documentation, website content, + etc.</p> - <p>At least one +2 from a committer and no -1 from any committer.</p> - </li> + <p>At least one +2 from a committer and no -1 from any committer.</p> + </li> - <li> - <strong>Product Release</strong> + <li> + <strong>Product Release</strong> - <p>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.</p> + <p>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.</p> - <p>Lazy Majority of active PMC members</p> - </li> + <p>Lazy Majority of active PMC members</p> + </li> + + <li> + <strong>Branch Creation or Deletion</strong> - <li> - <strong>New Branch Committer</strong> + <p>Speculative branches may be used for significant, pervasive features, + or release managers may create branches to test and stabilize release + candidates.</p> + + <p>Lazy consensus of active PMC members</p> + </li> - <p>When a branch committer is proposed for the PMC</p> + <li> + <strong>New Branch Committer</strong> - <p>Lazy consensus of active PMC members</p> - </li> + <p>When a branch committer is proposed for the PMC</p> - <li> - <strong>New Committer</strong> + <p>Lazy consensus of active PMC members</p> + </li> - <p>When a new committer is proposed for the project</p> + <li> + <strong>New Committer</strong> - <p>Consensus approval of active PMC members</p> - </li> + <p>When a new committer is proposed for the project</p> - <li> - <strong>New PMC Member</strong> + <p>Consensus approval of active PMC members</p> + </li> - <p>When a committer is proposed for the PMC</p> + <li> + <strong>New PMC Member</strong> - <p>Consensus approval of active PMC members</p> - </li> + <p>When a committer is proposed for the PMC</p> - <li> - <strong>Branch Committer Removal</strong> + <p>Consensus approval of active PMC members</p> + </li> - <p>When removal of commit privileges is sought <strong>or</strong> when the - branch is merged to the mainline</p> + <li> + <strong>Branch Committer Removal</strong> - <p>Lazy 2/3 majority of active PMC members</p> - </li> + <p>When removal of commit privileges is sought <strong>or</strong> when + the branch is merged to the mainline</p> - <li> - <strong>Committer Removal</strong> + <p>Lazy 2/3 majority of active PMC members</p> + </li> - <p>When removal of commit privileges is sought. Note: Such actions will - also be referred to the ASF board by the PMC chair</p> + <li> + <strong>Committer Removal</strong> - <p>Lazy 2/3 majority of active PMC members (excluding the committer in - question if a member of the PMC).</p> - </li> + <p>When removal of commit privileges is sought. Note: Such actions will + also be referred to the ASF board by the PMC chair</p> - <li> - <strong>PMC Member Removal</strong> + <p>Lazy 2/3 majority of active PMC members (excluding the committer in + question if a member of the PMC).</p> + </li> - <p>When removal of a PMC member is sought. Note: Such actions will also be - referred to the ASF board by the PMC chair.</p> + <li> + <strong>PMC Member Removal</strong> - <p>Lazy 2/3 majority of active PMC members (excluding the member in - question)</p> - </li> + <p>When removal of a PMC member is sought. Note: Such actions will also + be referred to the ASF board by the PMC chair.</p> - <li> - <strong>Modifying Bylaws</strong> + <p>Lazy 2/3 majority of active PMC members (excluding the member in + question)</p> + </li> - <p>Modifying this document.</p> + <li> + <strong>Modifying Bylaws</strong> - <p>Lazy majority of active PMC members</p> - </li> - </ul> - </li> + <p>Modifying this document.</p> - <li> - <strong>Voting Timeframes</strong> + <p>Lazy majority of active PMC members</p> + </li> + </ul> + </li> - <p>Votes are open for a period of 72 hours 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.</p> + <li> + <strong>Voting Timeframes</strong> - </li> - </ul> + <p>Votes are open for a period of 72 hours 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.</p> + </li> + </ul> + </div> </div> </div><!--+ |end content
