<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright 2002-2004 The Apache Software Foundation or its licensors,
as applicable.

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.3//EN" "http://forrest.apache.org/dtd/document-v13.dtd">
<document> 
<header> 
  <title>Apache Forrest project guidelines</title> 
</header> 
<body> 
  <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.
   Apache 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. These project guidelines supplement that
   ASF documentation. Normally these guidelines are not needed - the project
   just gets on with its day-to-day operation - but they enable
   all people to understand how the project operates.
  </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". This facilitates
      open collaborative development, with respect for others.
      For more information about how Apache projects operate, please refer to
      the
      <link href="http://www.apache.org/foundation/">ASF foundation</link>
      and
      <link href="http://www.apache.org/dev/">ASF developer</link> sections
      of the ASF website, including the
      <link href="http://www.apache.org/foundation/bylaws.html">ASF ByLaws</link>
      and the
      <link href="ext:how-it-works">How it works</link> document,
      as well as the
      <link href="http://incubator.apache.org/">Incubator project</link>.
    </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>
    <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.
      See explanation of the role of the PMC in that resolution and also the
      <link href="http://www.apache.org/foundation/bylaws.html">ASF Bylaws</link>
      and 
    <link href="http://www.apache.org/foundation/how-it-works.html#pmc">How-it-works</link>.
    </p>
    <p>The responsibilities of the PMC include:</p>
    <ul>
      <li>Be familiar with these project guidelines, and the
      ASF Bylaws, and with the ASF documentation and procedures
      in general.</li>
      <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>Strive for and help to facilitate a harmonious productive community.</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.
      See further explanation of the role of the chair in the
      <link href="http://www.apache.org/foundation/bylaws.html">ASF Bylaws</link>
      and the
      <link href="http://www.apache.org/dev/pmc.html#chair">PMC FAQ</link>
    </p>
  </section>

  <section id="decision">
    <title>Decision making</title>
    <p>
      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>

    <p>
      Most day-to-day operations do not require explicit voting - just get on
      and do the work. See the "Lazy approval" type described below.
    </p>

    <section id="voting">
      <title>Voting</title>
      <p>
        Certain actions and 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.
      </p>
      <p>
        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. 
        See <link href="#procedure">voting procedure</link> below.
        Votes are expressed using one of the following symbols:
      </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="#veto">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>

        <tr>
          <td><strong>abstain</strong></td>
          <td>People can abstain from voting. They can either remain
          silent or express their reason.
          </td>
        </tr>
      </table>

      <p>
        All participants in the project are encouraged to show their
        preference for a particular action by voting. When the votes are
        tallied, 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>
        Different actions require different types of approval:
      </p>

      <table>
        <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 PMC members.
            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>

        <tr>
          <td><strong>Unanimous consensus</strong></td>
          <td>
            All voters with binding votes must vote and there
            can be no binding vetoes (-1).
          </td>
        </tr>
      </table>
    </section>

    <section id="veto">
      <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.
      </p>

      <p>
        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. In case of disputes about whether
        a veto is valid, then opinion of the PMC chair is final.
      </p>

      <p>
        If you disagree with a valid veto, then you must engage the person
        casting the veto to further discuss the issues. The vetoer is obliged
        to vote early and to then work with the community to resolve
        the matter.
      </p>

      <p>
        If a veto is not withdrawn, the action that has been vetoed must
        be reversed in a timely manner.
      </p>
    </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 by a committer.
            This includes source code, documentation, website content, etc.
          </td>
          <td>
            Lazy approval
          </td>
          <td>
            Active PMC members
          </td>
        </tr>
        <tr>
          <td><strong>Release plan</strong></td>
          <td>
            Defines the timetable and actions for a release.
          </td>
          <td>
            Lazy majority
          </td>
          <td>
            Active PMC members
          </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 PMC members
          </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.
          </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.
            See also section 6.5 of the ASF Bylaws whereby the ASF Board may
            remove a PMC member.
          </td>
          <td>
            Unanimous consensus
          </td>
          <td>
            Active PMC members (excluding the member in question)
          </td>
        </tr>
      </table>
    </section>

    <section id="timeframe">
      <title>Voting timeframes</title>
      <p>
        Votes are open for a period of one week to allow all active voters
        time to consider the vote. If the vote has not achieved a quorum,
        then it can be extended for another week. If still no quorum, then
        the vote fails, and would need to be raised again later.
        Votes relating to code changes are not subject to a strict timetable,
        but should be made as timely as possible.
      </p>
    </section>

    <section id="procedure">
      <title>Voting procedure</title>
      <p>
        Discussion about the topic would have already happened in a [Proposal]
        email thread to express the issues and opinions. The [Vote] thread is
        to ratify the proposal.
      </p>
      <p>
        The instigator sends the Vote email to the dev mailing list.
        Describe the issue with no ambiguity and in a positive sense.
      </p>
      <p>
        Votes are expressed by replying email using the
        <link href="#voting">voting symbols</link> defined above.
        Voters can change their vote during the timeframe.
        At the end of the vote period, the instigator tallies the number of
        final votes and reports the results.
      </p>
    </section>

    <section id="ultimatum">
      <title>Ultimatum and breakdown</title>
      <p>
        For breakdown situations and those requiring unanimous consensus,
        if this consensus cannot be reached within the extended timeframe,
        then the Board expects the chair to act as the officer of the
        Foundation and make the ultimate decision.
      </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
> Cocoon committers are Forrest committers; something with xml-commons

==================
Mention the "Contributer License Agreement".
Who needs to send it? ... is it committers plus major contributers?

==================

-->
</body>
</document>
