You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ibatis.apache.org by te...@wush.net on 2004/11/30 02:15:59 UTC
r362 - site/trunk/src/documentation/content/xdocs
Author: ted
Date: 2004-11-29 19:15:59 -0600 (Mon, 29 Nov 2004)
New Revision: 362
Added:
� �site/trunk/src/documentation/content/xdocs/bylaws.xml
Modified:
� �site/trunk/src/documentation/content/xdocs/site.xml
Log:
Add draft ByLaws page.
Added: site/trunk/src/documentation/content/xdocs/bylaws.xml
===================================================================
--- site/trunk/src/documentation/content/xdocs/bylaws.xml� � � � 2004-11-30 00:41:03 UTC (rev 361)
+++ site/trunk/src/documentation/content/xdocs/bylaws.xml� � � � 2004-11-30 01:15:59 UTC (rev 362)
@@ -0,0 +1,298 @@
+<?xml version="1.0"?>
+<document url="./bylaws.xml">
+
+ �<header>
+ � �<title>Project Management Committee Bylaws</title>
+ �</header>
+
+<body>
+
+ � �<section>
+ � �<title>Roles & 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 "<em>Committer</em>". 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>
+
+ � �</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 iBATIS 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>
+
+ � �</section>
+
+ � �<section>
+ � �<title>Subprojects</title>
+
+ � �<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>
+
+ � �</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 "<em>Minimum Threshod Meritocracy</em>".
+ � �</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>
+ � � � �"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>
+ � � </section>
+
+ � �<section>
+ � �<title>Action Items</title>
+
+ � �<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>
+
+ � �</section>
+
+ � �<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>
Modified: site/trunk/src/documentation/content/xdocs/site.xml
===================================================================
--- site/trunk/src/documentation/content/xdocs/site.xml� � � � 2004-11-30 00:41:03 UTC (rev 361)
+++ site/trunk/src/documentation/content/xdocs/site.xml� � � � 2004-11-30 01:15:59 UTC (rev 362)
@@ -15,6 +15,7 @@
� �<community label="Community">
� � �<mailinglists label="Mailing Lists" href="mailinglists.html" />
+ � �<contributors label="ByLaws" href="bylaws.html" />
� � �<contributors label="Contributors" href="contributors.html" />
� �</community>