ibatis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@wush.net>
Subject r362 - site/trunk/src/documentation/content/xdocs
Date Tue, 30 Nov 2004 01:15:59 GMT
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 &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 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 &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>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>






Mime
View raw message