forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject svn commit: rev 47029 - forrest/trunk/src/documentation/content/xdocs
Date Wed, 22 Sep 2004 06:16:07 GMT
Author: crossley
Date: Tue Sep 21 23:16:06 2004
New Revision: 47029

Modified:
   forrest/trunk/src/documentation/content/xdocs/guidelines.xml
Log:
Add draft sections about "Decision making" and "Voting" and "PMC".


Modified: forrest/trunk/src/documentation/content/xdocs/guidelines.xml
==============================================================================
--- forrest/trunk/src/documentation/content/xdocs/guidelines.xml	(original)
+++ forrest/trunk/src/documentation/content/xdocs/guidelines.xml	Tue Sep 21 23:16:06 2004
@@ -1,90 +1,445 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!--
-  Copyright 2002-2004 The Apache Software Foundation
+Copyright 2002-2004 The Apache Software Foundation
 
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
 -->
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://forrest.apache.org/dtd/document-v12.dtd">
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.3//EN" "http://forrest.apache.org/dtd/document-v13.dtd">
 <document> 
-  <header> 
-    <title>DRAFT: Forrest Project Guidelines</title> 
-  </header> 
-  <body> 
-    <warning>
-      This document is under development on the forrest-dev mailing list.
-      PMC members please edit. Try to refer to 
-      <link href="http://www.apache.org/foundation/">foundation</link>
-      documents where appropriate.
-    </warning>
-    <p>
-     This document provides the guidelines under which the Apache Forrest project operates.
It defines the roles and responsibilities, who may vote, how voting works, how conflicts are
resolved, etc.
-     The Forrest project was established in January 2002 and became a
-     top-level project in
-     <link href="http://www.apache.org/foundation/records/minutes/2004/">May 2004</link>.
-<!-- FIXME: Link directly to the Board minutes when they are available.
--->
+<header> 
+  <title>DRAFT: Apache Forrest Project Guidelines</title> 
+</header> 
+<body> 
+  <warning>
+    This document is under development on the forrest-dev mailing list.
+    PMC members please edit. Try to refer to 
+    <link href="http://www.apache.org/foundation/">foundation</link>
+    documents where appropriate.
+  </warning>
+  <p>
+   This document provides the guidelines under which the Apache Forrest
+   project operates. It defines the roles and responsibilities, who may vote,
+   how voting works, how conflicts are resolved, etc.
+   Forrest is a project of the Apache Software Foundation
+   (<link href="http://www.apache.org/foundation/">ASF</link>) which holds
+   the copyright for all Apache projects. The ASF website explains the
+   operation and background of the ASF.
+  </p>
+
+  <section id="mission">
+    <title>The mission of Apache Forrest</title>
+    <p>
+      The generation of aggregated multi-channel documentation,
+      maintaining a separation of content and presentation.
+    </p>
+  </section>
+
+  <section id="way">
+    <title>The Apache Way</title>
+    <p>
+      Forrest 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
+      <link href="http://incubator.apache.org">Incubator project</link>
+      and the
+      <link href="http://www.apache.org/dev/">ASF developer</link> section
+      for more information about how Apache projects operate.
+    </p>
+  </section>
+
+  <section id="roles">
+    <title>Roles and responsibilities</title>
+    <p>The meritocracy enables various roles as defined in the
+      <link href="ext:how-it-works">How it works</link> document.
+    </p>
+    <p>
+    <!-- FIXME: Add to site.xml -->
+    <link href="http://www.apache.org/foundation/how-it-works.html#users">user</link>
-&gt;
+    <link href="http://www.apache.org/foundation/how-it-works.html#developers">developer</link>
-&gt;
+    <link href="http://www.apache.org/foundation/how-it-works.html#committers">committer</link>
-&gt;
+    <link href="http://www.apache.org/foundation/how-it-works.html#pmc-members">PMC
member</link> -&gt;
+    <link href="http://www.apache.org/foundation/how-it-works.html#asf-members">ASF
member</link>
+    </p>
+    <p>The current Apache Forrest committers and PMC members are
+      <link href="site:who">listed</link>.
+    </p>
+  </section>
+
+  <section id="pmc">
+    <title>Project Management Committee (PMC)</title>
+    <p>The Apache Forrest project was established in January 2002 and became a
+      top-level project in May 2004.
+      The Project Management Committee (PMC) was created by a
+      <link href="http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_05_26.txt">resolution</link>
+      of the board of the Apache Software Foundation. The PMC is
+      responsible to the board and the ASF for the management and oversight
+      of the Apache Forrest project and codebase.
+    </p>
+    <p>The responsibilities of the PMC include:</p>
+    <ul>
+      <li>Keep oversight of the commit log messages and ensure that
+       the codebase does not have copyright and license issues.</li>
+      <li>Resolve license disputes regarding products of the project,
+        including other supporting software that is re-distributed.</li>
+      <li>Decide what is distributed as products of the project.
+        In particular all releases must be approved by the PMC.</li>
+      <li>Guide the direction of the project.</li>
+      <li>Nominate new PMC members and committers.</li>
+      <li>Maintain the project's shared resources, including the
+        codebase repository, mailing lists, websites.</li>
+      <li>Speak on behalf of the project.</li>
+      <li>Maintain these and other guidelines of the project.</li>
+    </ul>
+    <p>
+      The PMC does have a private mailing list on which it can discuss
+      certain issues. However this list is rarely used and every effort
+      is made to conduct all discussion on the public mailing lists.
+    </p>
+
+    <p>
+      Membership of the PMC is by invitation only and must receive
+      consensus approval of the active PMC members.
+    </p> 
+    <p>
+      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. Membership of the PMC can be
+      revoked by unanimous consensus of all active PMC members (other than
+      the member in question).
+    </p>
+
+    <p>
+      The chair of the PMC is appointed by the Board and is an officer of
+      the ASF (Vice President). The chair has primary responsibility to the
+      Board, and has the power to establish rules and procedures for the
+      day to day management of the communities for which the PMC is
+      responsible, including the composition of the PMC itself.
+      The chair reports to the board quarterly on developments within the
+      project. The PMC may consider the position of PMC chair annually and 
+      may recommend a new chair to the board.
+      Ultimately, however, it is the board's responsibility who it chooses
+      to appoint as the PMC chair.
     </p>
+  </section>
+
+  <section id="decision">
+    <title>Decision making</title>
     <p>
-      Forrest is a project of the Apache Software Foundation
-      (<link href="http://www.apache.org/foundation/">ASF</link>) which holds
-      the copyright for all Apache projects. The ASF website explains the
-      operation and background of the ASF.
+      Within this project, different types of decisions require different
+      forms of approval. For example, the previous section describes
+      several decisions which require "consensus approval". This
+      section defines how voting is performed, the types of approval, and which
+      types of decision require which type of approval.
     </p>
 
-    <section id="mission">
-      <title>The mission of Forrest</title>
+    <section id="voting">
+      <title>Voting</title>
+      <p>
+        Decisions regarding the project are made by votes on the project
+        development mailing list. Where necessary,
+        PMC voting may take place on the private PMC mailing list.
+        Votes are clearly indicated by subject line starting with [VOTE].
+        Discussion and proposal should have happened prior to the vote.
+        Voting is carried out by replying to the vote mail. Voting may take
+        four flavours:
+      </p>
+
+      <table>
+        <tr>
+          <td><strong>+1</strong></td>
+          <td>
+            "Yes," "Agree," or "the action should be
+            performed." In general, this vote also indicates a willingness
+            on the behalf of the voter to assist with "making it happen".
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>+0</strong></td>
+          <td>
+            This vote indicates a willingness for the action under
+            consideration to go ahead. The voter, however will not be able
+            to help.
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>-0</strong></td>
+          <td>
+            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.
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>-1</strong></td>
+          <td>
+            This is a negative vote. On issues where consensus is required,
+            this vote counts as a <link href="#vetoes">veto</link>.
+            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.
+          </td>
+        </tr>
+      </table>
+
+      <p>
+        All participants in the project are encouraged to show their
+        preference for a particular action by voting. For actual
+        decisions, only the votes of PMC members are binding. Non-binding
+        votes are still useful to enable everyone to understand the
+        perception of an action by the wider community.
+      </p>
+
+      <p>
+        Voting can also be applied to changes made to the project codebase. These
+        typically take the form of a veto (-1) in reply to the commit message
+        sent when the commit is made.
+      </p>
+    </section>
+
+    <section id="approvals">
+      <title>Types of approval</title>
       <p>
-        The generation of aggregated multi-channel documentation,
-        maintaining a separation of content and presentation.
+        Different actions require different types of approval:
       </p>
+
+      <table>
+        <tr>
+          <td><strong>Unanimous consensus</strong></td>
+          <td>
+            All voters with binding votes must vote and there
+            can be no binding vetoes (-1). This type of approval is rarely required,
+            due to the impracticality of getting all eligible voters to cast a
+            vote.
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>Consensus approval</strong></td>
+          <td>
+            Consensus approval requires 3 binding +1 votes and no binding vetoes.
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>Lazy majority</strong></td>
+          <td>
+            A lazy majority vote requires 3 binding +1 votes and more binding +1
+            votes that -1 votes.
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>Lazy approval</strong></td>
+          <td>
+            An action with lazy approval is implicitly allowed unless a -1 vote
+            is received, at which time, depending on the type of action, either
+            lazy majority or consensus approval must be obtained.
+          </td>
+        </tr>
+
+        <tr>
+          <td><strong>2/3 majority</strong></td>
+          <td>
+            Some actions require a 2/3 majority of active committers or PMC
+            members to pass. Such actions typically affect the foundation
+            of the project (e.g. adopting a new codebase to replace an existing
+            product). The higher threshold is designed to ensure such changes
+            are strongly supported. To pass this vote requires at least 2/3 of
+            binding vote holders to vote +1
+          </td>
+        </tr>
+      </table>
     </section>
 
-    <section id="roles">
-      <title>Roles and responsibilities</title>
+    <section id="vetoes">
+      <title>Vetoes</title>
+      <p>
+        A valid veto cannot be over-ruled, it can only be withdrawn by its issuer.
+        Any veto must be accompanied by reasoning and be prepared to defend it.
+        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>
-        We use the roles as defined in the
-        <link href="ext:how-it-works">How it works</link> document.
+        If you disagree with a valid veto, you must engage the person casting
+        the veto, to convince them to withdraw it. If a veto is not withdrawn,
+        the action that has been vetoed must be reversed in a timely manner.
       </p>
     </section>
 
-    <section id="decisions">
-      <title>Decision making</title>
-      <section id="voting">
-        <title>Voting procedures</title>
-        <p>
-        We use the procedures as defined in the ASF
-        <link href="ext:voting">Voting</link> document.
-        </p>
-        <!--
-        <fixme author="open">
-          Add content, probably borrow from other projects,
-          like Ant and Incubator. Define +1, 0, -1, etc.
-          Define situations that require voting (e.g. technical issues,
-          new committers, project direction and decisions) and whose votes
-          are binding in those situations.
-        </fixme>
-        -->
-      </section>
+    <section id="actions">
+      <title>Actions</title>
+      <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>
+
+      <table>
+        <tr>
+          <th>Action</th>
+          <th>Description</th>
+          <th>Approval</th>
+          <th>Binding Votes</th>
+        </tr>
+        <tr>
+          <td><strong>Code change</strong></td>
+          <td>
+            A change made to a codebase of the project and committed
+            by a committer. This includes source code, documentation, website
+            content, etc.
+          </td>
+          <td>
+            Lazy approval
+          </td>
+          <td>
+            Active committers
+          </td>
+        </tr>
+        <tr>
+          <td><strong>Release plan</strong></td>
+          <td>
+            Defines the timetable and actions for a release. The plan also
+            nominates a Release Manager.
+          </td>
+          <td>
+            Lazy majority
+          </td>
+          <td>
+            Active committers
+          </td>
+        </tr>
+        <tr>
+          <td><strong>Product release</strong></td>
+          <td>
+            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.
+          </td>
+          <td>
+            Lazy majority
+          </td>
+          <td>
+            Active PMC members
+          </td>
+        </tr>
+        <tr>
+          <td><strong>Adoption of new codebase</strong></td>
+          <td>
+            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
+          </td>
+          <td>
+            2/3 majority
+          </td>
+          <td>
+            Active committers
+          </td>
+        </tr>
+        <tr>
+          <td><strong>New committer</strong></td>
+          <td>
+            When a new committer is proposed for the project.
+          </td>
+          <td>
+            Consensus approval
+          </td>
+          <td>
+            Active PMC members
+          </td>
+        </tr>
+        <tr>
+          <td><strong>New PMC member</strong></td>
+          <td>
+            When a new member is proposed for the PMC.
+          </td>
+          <td>
+            Consensus approval
+          </td>
+          <td>
+            Active PMC members
+          </td>
+        </tr>
+        <tr>
+          <td><strong>Reinstate emeritus member</strong></td>
+          <td>
+            An emeritus PMC member can be reinstated.
+          </td>
+          <td>
+            Consensus approval
+          </td>
+          <td>
+            Active PMC members (excluding the member in question)
+          </td>
+        </tr>
+        <tr>
+          <td><strong>Committer removal</strong></td>
+          <td>
+            When removal of commit privileges is sought. Such actions will
+            also be referred to the ASF board by the PMC chair.
+          </td>
+          <td>
+            Unanimous consensus
+          </td>
+          <td>
+            Active PMC members (excluding the committer in question if a
+            member of the PMC)
+          </td>
+        </tr>
+        <tr>
+          <td><strong>PMC member removal</strong></td>
+          <td>
+            When removal of a PMC member is sought. Such actions will
+            also be referred to the ASF board by the PMC chair.
+          </td>
+          <td>
+            Unanimous consensus
+          </td>
+          <td>
+            Active PMC members (excluding the member in question)
+          </td>
+        </tr>
+      </table>
     </section>
 
-    <section id="code">
-      <title>Code management</title>
+    <section id="timeframe">
+      <title>Voting timeframes</title>
       <p>
-      Commit then review.
+        Votes are open for a period of one week 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>
     </section>
+  </section>
+
+  <section id="code">
+    <title>Code management</title>
+    <p>
+    <link href="http://www.apache.org/foundation/glossary.html#CommitThenReview">Commit-then-review</link>.
+    </p>
+  </section>
 
-<!--
+<!-- FIXME:
 
 ==================
 > We should make mention somewhere of our relationship to other projects
@@ -97,5 +452,5 @@
 ==================
 
 -->
-  </body>
+</body>
 </document>

Mime
View raw message