myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mat...@apache.org
Subject cvs commit: incubator-myfaces/src/documentation/content/xdocs/community bylaws.xml
Date Mon, 10 Jan 2005 15:30:16 GMT
matzew      2005/01/10 07:30:16

  Modified:    src/documentation/content/xdocs/community bylaws.xml
  Log:
  changed bylaws.xml
  
  Revision  Changes    Path
  1.2       +296 -349  incubator-myfaces/src/documentation/content/xdocs/community/bylaws.xml
  
  Index: bylaws.xml
  ===================================================================
  RCS file: /home/cvs/incubator-myfaces/src/documentation/content/xdocs/community/bylaws.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- bylaws.xml	10 Jan 2005 07:23:15 -0000	1.1
  +++ bylaws.xml	10 Jan 2005 15:30:16 -0000	1.2
  @@ -14,364 +14,311 @@
     See the License for the specific language governing permissions and
     limitations under the License.
   -->
  -<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
   <document>
   
     <header>
  -    
  -    <title>Apache MyFaces Project Bylaws</title>
  +    <title>Project Management Committee Bylaws</title>
     </header>
  -  <body>
   
  -    <section><title>Apache MyFaces Project Bylaws</title>
  +<body>
   
  -      <p>This document defines the bylaws under which the Apache MyFaces
  -      project operates. It defines the roles and responsibilities of
  -      the project, who may vote, how voting works, how conflicts are
  -      resolved, etc.</p>
  -
  -      <p>MyFaces is a project of the <link
  -      href="http://www.apache.org/foundation/">Apache Software
  -      Foundation</link>.  The foundation holds the copyright on Apache
  -      code including the code in the MyFaces codebase. The <link
  -      href="http://www.apache.org/foundation/faq.html">foundation
  -      FAQ</link> explains the operation and background of the
  -      foundation.</p>
  -
  -      <p>MyFaces 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>
  -      for more information on how Apache projects operate.</p>
  -    </section>
  -
  -    <section><title>Roles and Responsibilities</title>
  -
  -      <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>
  -
  -      <section><title>Users</title>
  -  
  -        <p>The most important participants in the project are people
  -        who use our software. The majority of our developers start out
  -        as users and guide their development efforts from the user's
  -        perspective.</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>
  -      </section>
  -
  -      <section><title>Developers</title>
  -  
  -        <p>All of the volunteers who are contributing time, code,
  -        documentation, or resources to the MyFaces Project. A developer
  -        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>
  -      </section>
  -
  -      <section><title>Committers</title>
  -  
  -        <p>The project's Committers are responsible for the project's
  -        technical management. All committers have write access to the
  -        project's source repositories. Committers may cast binding
  -        votes on any technical discussion regarding the project.</p>
  -
  -        <p>All Developers who are already committers for any other
  -        Apache code-base automatically obtain commit access to the
  -        MyFaces project as well.</p>
  -
  -        <p>Committer access is by invitation only and must be approved
  -        by lazy consensus of the active PMC members. A Committer is
  -        considered emeritus by their own declaration or by not
  -        contributing in any form to the project for over six
  -        months. An emeritus committer may request reinstatement of
  -        commit access from the PMC. Such reinstatement is subject to
  -        lazy consensus of active PMC members.</p>
  -
  -        <p>Commit access can be revoked by a unanimous vote of all the
  -        active PMC members (except the committer in question if they
  -        are also a PMC member).</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 <link
  -        href="http://www.apache.org/dev/committers.html">Committer
  -        FAQ</link> which provides more details on the requirements for
  -        Committers.</p>
  -
  -        <p>A committer who makes a sustained contribution to the
  -        project may be invited by or ask the PMC 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, etc.</p>
  -      </section>
  -
  -      <section><title>Project Management Committee</title>
  -  
  -        <p>The Project Management Committee (PMC) for Apache MyFaces was
  -        created by a resolution of the board of the Apache Software
  -        Foundation on 18th February 2004. The PMC is responsible to
  -        the board and the ASF for the management and oversight of the
  -        Apache MyFaces codebase. The responsibilities of the PMC
  -        include</p>
  +    <section>
  +    <title>Roles &amp; Responsibilities</title>
  +
  +    <p>
  +    The roles and responsibilities that people can assume in the project
  +    are based on merit. Everybody can help no matter what their role.
  +    Those who have been longterm or valuable contributors to the project
  +    can earn the right to commit directly to the source repository and to
  +    cast binding votes during the decision-making process.
  +    </p>
  +
  +    <p>
  +    <strong>Users.</strong>
  +    Users are the people who use the products of the Project. People in
  +    this role aren't contributing code, but they are using the products,
  +    reporting bugs, making feature requests, and such. This is by far
  +    the most important category of people as, without users, there is no
  +    reason for the Project. When a user starts to contribute code or
  +    documentation patches, they become a Contributor.
  +    </p>
  +
  +    <p>
  +
  +    <strong>Contributors.</strong>
  +    Contributors are the people who write code or documentation patches or
  +    contribute positively to the project in other ways. When a volunteer's
  +    patch is applied, the contribution is recognized in the version control
  +    log.
  +    </p>
  +
  +    <p>
  +    <strong>Committers.</strong>
  +    Contributors who give frequent and valuable contributions to 
  +    the Project can have their status promoted to that of
  +    a &quot;<em>Committer</em>&quot;. A Committer has write access
to the 
  +    source code repository. Committer status is granted by the Project 
  +    Management Committee by majority vote.
  +    </p>
  +
  +    <p>
  +    <strong>Project Management Committee (PMC).</strong>
  +    Committers and other volunteers who frequently participate with
  +    valuable contributions may have their status promoted to that of a
  +    &quot;<em>Project Management Committee Member</em>&quot;. The PMC
  +    is responsible for the day-to-day management of the Project.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +
  +    <title>Management</title>
  +    <p>
  +    The Vice President is (or will be) appointed by the ASF Board. The Vice
  +    President is assisted by the Project Management Committee (PMC)
  +    and also serves as the PMC chair. The PMC may nominate new
  +    members. Nominees may then be approved with a 3/4 majority vote
  +    of the PMC. Membership can be revoked by a unanimous vote of all
  +    the active PMC members other than the member in question. 
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>PMC Duties</title>
  +
  +    <p>
  +    The PMC is responsible for the day-to-day
  +    management of the Project. The PMC oversees all changes
  +    made to the codebase. The PMC must ensure that all code under a
  +    Apache MyFaces repository is the lawful property of the Foundation and
  +    may be distributed under the <a href="http://apache.org/licenses/">
  +    Apache Software License</a>. All releases of an MyFaces subproject
  +    must be sanctioned by the Project Management Committee.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Subprojects</title>
  +
  +    <p>
  +    Subprojects are the Project's unit of release. Each subproject should
  +    represent an implementation of the MyFaces core or a related component.
  +    Each subproject should focus on creating, maintaining, and releasing a
  +    single software product or "deliverable".
  +    </p>
  +
  +    <p>
  +    All PMC Members have voting rights in all subprojects. Members not familiar
  +    with a subproject codebase may abstain from any given vote. All Committers
  +    have write access to all subprojects. Subprojects are units of release, not
  +    units of work.
  +    </p>
  +
  +    <p>
  +    PMC members may propose the creation of new subprojects. Proposals are
  +    to contain the scope of the project, identify the initial source from
  +    which the project is to be populated, identify any mailing lists or
  +    repositories, if any, which are to be created. Creation of a new
  +    subproject requires approval by a 3/4 majority vote of the PMC.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Decision Making</title>
  +
  +    <p>
  +    All Volunteers are encouraged to participate in decisions, but the
  +    decision itself is made by the Project Management Committee.
  +    The Project is a &quot;<em>Minimum Threshod Meritocracy</em>&quot;.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Voting</title>
  +
  +    <p>
  +    Any subscriber to the list may vote on any issue or action item.
  +    Votes from Contributors and Committers are especially welcome.
  +    However, the only binding votes are those cast by a PMC Member.
  +    </p>
  +
  +    <p>
  +
  +    The act of voting carries certain obligations. Voters are not only
  +    stating their opinion, they are also agreeing to help do the work.
  +    </p>
  +
  +    <p>Each vote can be made in one of three flavors:</p>
  +
  +    <table>
  +    <tr>
  +    <td><strong>+1</strong></td>
  +    <td>
  +
  +        &quot;Yes,&quot; &quot;Agree,&quot; or &quot;the action should
be
  +        performed.&quot; On some issues this is only binding if the voter
  +        has tested the action on their own system(s).
  +    </td>
  +    </tr>
  +
  +    <tr>
  +    <td><strong>+/-0</strong></td>
  +
  +    <td>
  +        &quot;Abstain,&quot; &quot;no opinion&quot;. An abstention may
  +        have detrimental effects if too many people abstain.
  +    </td>
  +    </tr>
  +
  +    <tr>
  +    <td><strong>-1</strong></td>
  +    <td>
  +
  +        <p>
  +        &quot;No.&quot; On issues where consensus is required, this vote
  +        counts as a <strong>veto</strong>. All vetos must contain an
  +        explanation of why the veto is appropriate. Vetos with no
  +        explanation are void. A veto cannot be overruled. If you disagree
  +        with the veto, you should lobby the person who cast the veto.
  +        Voters intending to veto an action item should make their opinions
  +        known to the group immediately so that the problem can be remedied
  +        as early as possible.
  +        </p>
  +        <p>
  +        If a Committer tries to "override" a veto by restoring a vetoed
  +        change, the PMC may ask the infrastructure team to revoke that
  +        Committer's write privileges.
  +        </p>
  +    </td>
  +    </tr>
  +
  +    </table>
  +
  +    <p>
  +    An action requiring consensus approval must receive at least
  +    <strong>3 binding +1</strong> votes and <strong>no binding
  +    vetos</strong>. An action requiring majority approval must receive
  +    at least <strong>3 binding +1</strong> votes and more
  +    <strong>+1</strong> votes than <strong>-1</strong> votes. All
other
  +    action items are considered to have lazy approval until somebody
  +    votes <strong>-1</strong>, after which point they are decided by
  +    either consensus or majority vote, depending on the type of action
  +    item.
  +    </p>
  +
  +    <p>
  +    Voting represent consensus and votes are never final. Circumstances
  +    change, and so may votes. A veto may be converted to a +1 after
  +    discussion, and likewise a +1 may be converted to a -1.
  +    By convention, Committers should allow a vote to circulate for 72
  +    hours before taking action.
  +    </p>
  +     </section>
  +
  +    <section>
  +    <title>Action Items</title>
  +
  +    <p>
  +    All decisions revolve around &quot;<em>Action
  +    Items.</em>&quot; Action Items consist of the following:
  +    </p>
   
           <ul>
  -          <li>Deciding what is distributed as products of the Apache
  -          MyFaces 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, 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>
  +            <li>Long Term Plans</li>
  +            <li>Short Term Plans</li>
  +            <li>Product Changes</li>
  +            <li>Showstoppers</li>
  +            <li>Release Plan</li>
  +
  +            <li>Release Grade</li>
           </ul>
   
  -        <p>Membership of the PMC is by invitation only and must be
  -        approved by a lazy consensus of active PMC members. A PMC
  -        member is considered "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 lazy consensus of the
  -        active PMC members. Membership of the PMC can be revoked by an
  -        unanimous vote of all the active PMC members other than the
  -        member in question.</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 MyFaces) and has primary responsibility
  -        to the board for the management of the projects within the
  -        scope of the MyFaces PMC. The chair reports to the board
  -        quarterly on developments within the MyFaces project.  The PMC
  -        may consider the position of PMC chair annually and if
  -        supported by 2/3 Majority 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>
  -
  -    <section><title>Decision Making</title>
  -
  -      <p>Within the MyFaces project, different types of decisions require
  -      different forms of approval. For example, the previous section
  -      describes several decisions which require "lazy consensus"
  -      approval. This section defines how voting is performed, the
  -      types of approvals, and which types of decision require which
  -      type of approval.</p>
  -
  -      <section><title>Voting</title>
  -  
  -        <p>Decisions regarding the project are made by votes on the
  -        primary project mailing list (general@MyFaces.apache.org). Where
  -        necessary, PMC voting may take place on the private MyFaces PMC
  -        mailing list - this is generally true for votes on people,
  -        i.e. electing new committers or PMC members or removing these
  -        rights.  Votes are clearly indicated by subject line starting
  -        with [VOTE] or [PMC-VOTE]. Votes may contain multiple items
  -        for approval and these should be clearly separated. Voting is
  -        carried out by replying to the vote mail. Voting may take four
  -        flavours</p>
  -
  -        <table>
  -          <tr>
  -            <th>+1</th>
  -            <td>"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"</td>
  -          </tr>
  -          <tr>
  -            <th>+0</th>
  -            <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>
  -            <th>-0</th>
  -            <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>
  -            <th>-1</th>
  -            <td>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.</td>
  -          </tr>
  -        </table>
  -
  -        <p>All participants in the MyFaces 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 MyFaces community. For PMC decisions, only
  -        the votes of PMC members are binding.</p>
  -
  -        <p>Voting can also be applied to changes made to the MyFaces
  -        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><title>Approvals</title>
  -  
  -        <p>These are the types of approvals that can be
  -        sought. Different actions require different types of
  -        approvals</p>
  -
  -        <table>
  -          <tr>
  -            <th>Consensus</th>
  -            <td>For this to pass, all voters with binding votes must
  -            vote and there can be no binding vetoes (-1). Consensus
  -            votes are rarely required due to the impracticality of
  -            getting all eligible voters to cast a vote.</td>
  -          </tr>
  -          <tr>
  -            <th>Lazy Consensus</th>
  -            <td>Lazy consensus requires 3 binding +1 votes and no
  -            binding vetoes.</td>
  -          </tr>
  -          <tr>
  -            <th>Lazy Majority</th>
  -            <td>A lazy majority vote requires 3 binding +1 votes and
  -            more binding +1 votes that -1 votes.</td>
  -          </tr>
  -          <tr>
  -            <th>Lazy Approval</th>
  -            <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 lazy consensus
  -            approval must be obtained.</td>
  -          </tr>
  -          <tr>
  -            <th>2/3 Majority</th>
  -            <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><title>Vetoes</title>
  -  
  -        <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, the action that has been vetoed must be
  -        reversed in a timely manner.</p>
  -      </section>
  -
  -      <section><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>
  -            <th>Code Change</th>
  -            <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 and then lazy consensus.</td>
  -            <td>Active committers.</td>
  -          </tr>
  -          <tr>
  -            <th>Release Plan</th>
  -            <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>
  -            <th>Product Release</th>
  -            <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>
  -            <th>Adoption of New Codebase</th>
  -            <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>
  -            <th>New Committer</th>
  -            <td>When a new committer is proposed for the project</td>
  -            <td>Lazy consensus</td>
  -            <td>Active PMC members</td>
  -          </tr>
  -          <tr>
  -            <th>New PMC Member</th>
  -            <td>When a committer is proposed for the PMC</td>
  -            <td>Lazy consensus</td>
  -            <td>Active PMC members</td>
  -          </tr>
  -          <tr>
  -            <th>Committer Removal</th>
  -            <td>When removal of commit privileges is
  -            sought. <strong>Note:</strong> Such actions will also be
  -            referred to the ASF board by the PMC chair</td>
  -            <td>Consensus</td>
  -            <td>Active PMC members (excluding the committer in
  -            question if a member of the PMC).</td>
  -          </tr>
  -          <tr>
  -            <th>PMC Member Removal</th>
  -            <td>When removal of a PMC member is
  -            sought. <strong>Note:</strong> Such actions will also be
  -            referred to the ASF board by the PMC chair</td>
  -            <td>Consensus</td>
  -            <td>Active PMC members (excluding the member in question).</td>
  -          </tr>
  -        </table>
  -      </section>
  -
  -      <section><title>Voting Timeframes</title>
  -  
  -        <p>Votes are open for a period of 1 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>
  -  </body>
  +
  +    <section>
  +    <title>Long Term Plans</title>
  +
  +    <p>
  +
  +    Long term plans are simply announcements that group members are
  +    working on particular issues related to the Project. These are not
  +    voted on, but Committers and PMC Members who do not agree with a
  +    particular plan, or think that an alternative plan would be better,
  +    are obligated to inform the group of their feelings.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Short Term Plan</title>
  +
  +    <p>
  +    Short term plans are announcements that a volunteer is working on a
  +    particular set of documentation or code files with the implication
  +    that other volunteers should avoid them or try to coordinate their
  +    changes.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Product Changes</title>
  +
  +    <p>
  +    All product changes to the repository are subject to
  +    lazy consensus.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Showstoppers</title>
  +
  +    <p>
  +    Showstoppers are issues that require a fix be in place before the
  +    next public release. They are listed in the status file in order to
  +    focus special attention on these problems. An issue becomes a
  +    showstopper when it is listed as such in the status file and remains
  +    so by lazy consensus.
  +    </p>
  +
  +    </section>
  +
  +    <section>
  +
  +    <title>Release Plan</title>
  +
  +      <p>
  +      A release plan must be used to keep all volunteers aware of when a
  +      release is desired, whether it will be a major, minor, or
  +      milestone release, who will be the release manager, when the
  +      repository will be tagged to create the distribution, and other assorted
  +      information to keep volunteers from tripping over each other. A release
  +      plan must be announced to the DEV list. Lazy majority decides each issue
  +      in a release plan.
  +      </p>
  +
  +    </section>
  +
  +    <section>
  +    <title>Release Grade</title>
  +
  +    <p>
  +    After a proposed release is built, it must be tested and classified before
  +    being released to the general public. The proposed release may be assigned
  +    "Alpha", "Beta" or "General Availability" classifications by majority vote.
  +    Once a release is classified by the PMC Members, it may be distributed to
  +    the general public on behalf of the Foundation. Distributions may be
  +    reclassified or withdrawn by majority vote, but the release number may not
  +    be reused by another distribution.
  +    </p>
  +
  +    </section>
  +
  +</body>
   </document>
  
  
  

Mime
View raw message