📄 bylaws.html
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Project Management Committee Bylaws</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<link href="./struts.css" type="text/css" rel="stylesheet" />
</head>
<body>
<div id="heading">
<a href="http://apache.org/">
<img id="asf_logo_wide" alt="The Apache Project" src="./images/asf_logo_wide.gif" />
</a>
<a href="http://struts.apache.org/">
<img id="struts-logo" alt="Struts Framework" src="./images/struts.gif" />
</a>
</div>
<!--end heading-->
<div id="content">
<div id="menu">
<p>Struts</p>
<ul>
<li>
<a href="index.html">Welcome</a>
</li>
<li>
<a href="learning.html">Learning</a>
</li>
<li>
<a href="acquiring.html">Acquiring</a>
</li>
<li>
<a href="using.html">Using</a>
</li>
<li>
<a href="volunteers.html">Who We Are</a>
</li>
<li>
<a href="announce.html">Announcements</a>
</li>
</ul>
<p>Documentation</p>
<ul>
<li>
<a href="userGuide/index.html">User and Developer Guides</a>
</li>
<li>
<a href="userGuide/release-notes.html">Release Notes</a>
</li>
<li>
<a href="api/index.html">Javadoc</a>
</li>
<li>
<a href="faqs/index.html">FAQs and Howtos</a>
</li>
</ul>
<p>Community</p>
<ul>
<li>
<a href="http://jakarta.apache.org/site/bugs.html">Known Issues (Bugzilla)</a>
</li>
<li>
<a href="http://wiki.apache.org/struts">Wiki Pages</a>
</li>
<li>
<a href="http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=241">List Archive</a>
</li>
<li>
<a href="http://wiki.apache.org/struts/StrutsResources">Resource Directory</a>
</li>
</ul>
<p>Download</p>
<ul>
<li>
<a href="http://struts.apache.org/download.cgi">Binaries</a>
</li>
<li>
<a href="http://struts.apache.org/download.cgi">Source Code</a>
</li>
<li>
<a href="http://svn.apache.org/dist/struts/">Development Releases</a>
</li>
</ul>
<p>Development</p>
<ul>
<li>
<a href="bylaws.html">Bylaws</a>
</li>
<li>
<a href="releases.html">Release Guidelines</a>
</li>
<li>
<a href="roadmap.html">Roadmap</a>
</li>
<li>
<a href="http://svn.apache.org/viewcvs.cgi/struts/action/branches/STRUTS_1_2_BRANCH/">Source Repository</a>
</li>
</ul>
</div>
<!--end menu-->
<div id="main">
<h1>Apache Struts Project Bylaws</h1>
<h2>Charter</h2>
<div class="indent">
<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>
</div>
<h2>Roles & Responsibilities</h2>
<div class="indent">
<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>
</div>
<h2>Management</h2>
<div class="indent">
<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>
</div>
<h2>PMC Duties</h2>
<div class="indent">
<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>
</div>
<h2>Subprojects</h2>
<div class="indent">
<p>
Subprojects are the Project's unit of release. Each subproject should
represent an implementation of the Struts 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>
</div>
<h2>Decision Making</h2>
<div class="indent">
<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 Threshod Meritocracy</em>".
</p>
</div>
<h2>Voting</h2>
<div class="indent">
<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>
</div>
<h2>Action Items</h2>
<div class="indent">
<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>
</div>
<h2>Long Term Plans</h2>
<div class="indent">
<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>
</div>
<h2>Short Term Plan</h2>
<div class="indent">
<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>
</div>
<h2>Product Changes</h2>
<div class="indent">
<p>
All product changes to the repository are subject to
lazy consensus.
</p>
</div>
<h2>Showstoppers</h2>
<div class="indent">
<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>
</div>
<h2>Release Plan</h2>
<div class="indent">
<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>
</div>
<h2>Release Grade</h2>
<div class="indent">
<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>
</div>
<hr class="section" />
<div class="indent">
<p class="right">
Next: <a href="releases.html">Release Guidelines</a>
</p>
</div>
</div>
<!--end main-->
</div>
<!--end content-->
<div id="footer">
<img id="powered-logo" alt="Powered by Struts" src="./images/struts-power.gif" />
Copyright (c) 2000-2005, The Apache Software Foundation <span class="noprint">-
<a href="http://wiki.apache.org/struts/StrutsDocComments">Comments?</a>
</span>
</div>
<!--end footer-->
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -