| <?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 " |
| <em>Committer</em> |
| " 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 |
| " |
| <em>Project Management Committee Member</em> |
| ". 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 " |
| <em>Minimum Threshold Meritocracy</em> |
| ". |
| </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> |
| "Yes," "Agree," or "the |
| action should be |
| performed." 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> |
| "Abstain," "no opinion". An |
| abstention may |
| have detrimental effects if too many people |
| abstain. |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <strong>-1</strong> |
| </td> |
| <td> |
| <p> |
| "No." 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 " |
| <em>Action |
| Items.</em> |
| " 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> |
