You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@impala.apache.org by jb...@apache.org on 2016/08/29 16:15:54 UTC
incubator-impala git commit: Update bylaws: Lazy Consensus for branch
creation and deletion.
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 <jb...@cloudera.com>
Tested-by: Jim Apple <jb...@cloudera.com>
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 <jb...@cloudera.com>
Authored: Thu Aug 18 15:55:22 2016 -0700
Committer: Jim Apple <jb...@cloudera.com>
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 (dev@impala.incubator.apache.org). 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 (dev@impala.incubator.apache.org). 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