<?xml version="1.0"?>
<!--
Copyright 1999-2005 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.
-->
<!--
// ======================================================================== 78
-->
<document>

    <properties>
        <title>Project Management Committee Charter</title>
    </properties>

    <body>

        <section name="Apache Struts PMC Charter">

            <p>
                Struts is a Project of the
                <a href="http://apache.org/foundation">
                    Apache Software Foundation</a>
                (ASF), formed by a resolution of the
                <a href="http://apache.org/foundation/board/">ASF Board of
                    Directors</a>
                . As an ASF Project, Struts is subject to the
                <a href="http://apache.org/foundation/bylaws.html">ASF
                    Bylaws</a>
                and the direction of the ASF Board.
            </p>

            <subsection name="Roles and Responsibilities">

                <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 a
                    subproject of the Project can have their status promoted
                    to that of
                    a &quot;
                    <em>Committer</em>
                    &quot; for that subproject. 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>

            </subsection>

            <subsection name="Management">

                <p>
                    The Vice President is 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.
                    The
                    list of active PMC members can be found on our
                    <a href="volunteers.html">Volunteers page</a>
                    .
                </p>

            </subsection>

            <subsection name="PMC Duties">

                <p>
                    The PMC is responsible for the day-to-day
                    management of the Struts Project. The PMC oversees all
                    changes
                    made to the codebase. The PMC must ensure that all code
                    under a
                    Apache Struts 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 a Struts subproject
                    must be sanctioned by the Project Management Committee.
                </p>

            </subsection>

            <subsection name="Subprojects">

                <p>
                    Subprojects are the Project's unit of release. Each
                    subproject should
                    represent an implementation of a Struts framework 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>

            </subsection>

            <subsection name="Decision Making">

                <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 Threshold Meritocracy</em>
                    &quot;.
                </p>

            </subsection>

            <subsection name="Voting">

                <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>
            </subsection>

            <subsection name="Action Items">

                <p>
                    All decisions revolve around &quot;
                    <em>Action
                        Items.</em>
                    &quot; Action Items consist of the following:
                </p>

                <ul>
                    <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>

            </subsection>

            <subsection name="Long Term Plans">

                <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>

            </subsection>

            <subsection name="Short Term Plan">

                <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>

            </subsection>

            <subsection name="Product Changes">

                <p>
                    All product changes to the repository are subject to
                    lazy consensus.
                </p>

            </subsection>

            <subsection name="Showstoppers">

                <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>

            </subsection>

            <subsection name="Release Plan">

                <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>

            </subsection>

            <subsection name="Release Grade">

                <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>

            </subsection>
        </section>

        <section>
            <p class="right">
                Next:
                <a href="releases.html">Release Guidelines</a>
            </p>
        </section>

    </body>
</document>