Author: nslater
Date: Sun Aug 17 19:19:12 2014
New Revision: 1618509
URL: http://svn.apache.org/r1618509
Log:
Minor formatting changes
Modified:
couchdb/site/bylaws.html
Modified: couchdb/site/bylaws.html
URL:
http://svn.apache.org/viewvc/couchdb/site/bylaws.html?rev=1618509&r1=1618508&r2=1618509&view=diff
==============================================================================
--- couchdb/site/bylaws.html (original)
+++ couchdb/site/bylaws.html Sun Aug 17 19:19:12 2014
@@ -8,13 +8,13 @@
<h1>CouchDB Bylaws</h1>
-<p><em>These bylaws were officially adopted by the CouchDB PMC as of 31 July
2014.</em>
+<p><em>This document was officially adopted by the CouchDB PMC as of 31 July
2014.</em>
- <h2>Table of Contents</h2>
+<h2>Table of Contents</h2>
<div class="toc"></div>
- <h2 id="intro">1. Introduction</h2>
+<h2 id="intro">1. Introduction</h2>
<p>This document defines the bylaws under which the Apache CouchDB project
operates. It defines the <a href="#roles">roles and responsibilities</a> within
the project, who may vote, how <a href="#voting">voting</a> works, how
conflicts are resolved, and voting rules for specific <a href="#types">decision
types</a>.
@@ -41,7 +41,7 @@
<p>Finally, use of these bylaws to enforce the letter of any rule and not its
spirit (also known as "<a
href="https://en.wikipedia.org/wiki/Rules_lawyer";>rule lawyering</a>") is not
acceptable behaviour.
- <h2 id="roles">2. Roles and Responsibilities</h2>
+<h2 id="roles">2. Roles and Responsibilities</h2>
<p><strong>The ASF <a
href="https://www.apache.org/foundation/how-it-works.html#roles";>defines a set
of roles</a> with associated rights and responsibilities. These roles govern
what tasks an individual may perform within the project. The roles are defined
in the following sections.</strong>
@@ -55,7 +55,7 @@
<p>We expect you to act in good faith. This is very important for a community
that depends so heavily on trust.
- <h3 id="users">2.1. Users</h3>
+<h3 id="users">2.1. Users</h3>
<p><strong>The most important participants in the project are people who use
our software.</strong>
@@ -69,7 +69,7 @@
<p>A contributor who makes sustained contributions to the project may be
invited to become a committer.
- <h3 id="committers">2.3. Committers</h3>
+<h3 id="committers">2.3. Committers</h3>
<p><strong>A committer is someone who is committed to the project. In return
for their commitment, they are given a binding vote in certain project
decisions. Committers are hence responsible for the ongoing health of the
project and the community.</strong>
@@ -96,7 +96,7 @@
<p>A committer who makes a sustained contribution to the project may be
invited to become a <em>Project Management Committee</em> (PMC) member.
- <h3 id="pmc">2.4. Project Management Committee</h3>
+<h3 id="pmc">2.4. Project Management Committee</h3>
<p><strong>The <em>Project Management Committee</em> (PMC) is responsible for
the management of the project.</strong>
@@ -120,7 +120,7 @@
<p>While security issues and release management are the responsibility of the
PMC, the PMC typically delegates this to committers.
- <h3 id="chair">2.5. Chair</h3>
+<h3 id="chair">2.5. Chair</h3>
<p><strong>The project Chair is a PMC member responsible for Foundation level
administrative tasks.</strong> It is not a technical leadership position,
meaning the Chair has no special say in ordinary project decisions. But we do
think of it as a cultural leadership position. Accordingly, position on
cultural issues is something to consider when electing a Chair.
@@ -134,11 +134,11 @@
<p>The Chair has a 12 month term. The intention of this term is to allow for a
rotation of the role amongst the PMC members. This does not prohibit the PMC
from selecting the same Chair to serve consecutive terms.
- <h3 id="board">2.6. Board of Directors</h3>
+<h3 id="board">2.6. Board of Directors</h3>
<p><strong>The Chair is responsible for the project to the Board of Directors
(the Board) of the ASF.</strong> The Board is the nine-person legal governing
body of the ASF, elected by the <a
href="http://apache.org/foundation/members.html";>members</a> of the Foundation.
The Board provides the oversight of the Foundation's activities and operation,
and has the responsibility of applying and enforcing the <a
href="http://apache.org/foundation/bylaws.html";>ASF's bylaws</a>.
- <h2 id="decisions">3. Decision Making</h2>
+<h2 id="decisions">3. Decision Making</h2>
<p>This section explains our approach to decision making and the formal
structures we have in place to make this as easy as possible.
@@ -158,7 +158,7 @@
<p>Our decision making processes are designed to reduce blockages. It is
understood that people come and go as time permits. It is not practical to hear
from everybody on every decision. Sometimes, this means a decision will be
taken while you are away from the project. It is reasonable to bring such
decisions up for discussion again, but this should be kept to a minimum.
- <h3 id="lazy">3.1. Lazy Consensus</h3>
+<h3 id="lazy">3.1. Lazy Consensus</h3>
<p><strong>When you are convinced that you know what the community would like
to see happen, you can assume that you already have permission and get on with
the work. We call this <a
href="http://www.apache.org/foundation/glossary.html#LazyConsensus";>lazy
consensus</a>.</strong> You don't have to insist that people discuss or approve
your plan, and you certainly don't need to call a vote. Just assume your plan
is okay unless someone says otherwise. This applies to anything in the list of
<a href="#types">decision types</a> in section 3.6. where lazy consensus is
allowed.
@@ -181,7 +181,7 @@
<p>An important side effect of this policy is that <em>silence is assent</em>.
There is no need for discussion, and no need for agreement to be voiced. If you
make a proposal to the list and nobody responds, that should be interpreted as
implicit support for your idea, and not a lack of interest. This can be hard to
get used to, but is an important part of how we do things.
- <h3 id="discussion">3.2. Discussion</h3>
+<h3 id="discussion">3.2. Discussion</h3>
<p><strong>If lazy consensus fails (i.e. someone objects) you can start a
discussion or you can abandon the proposal.</strong>
@@ -195,7 +195,7 @@
<p>Voting is a failure mode of discussion. But that doesn't mean you should
avoid it. It is a very powerful tool that should be used to terminate a
seemingly interminable discussion. Knowing when to end a discussion and call a
vote is one of the most useful skills a contributor can master.
- <h3 id="voting">3.3. Voting</h3>
+<h3 id="voting">3.3. Voting</h3>
<p><strong><a href="https://www.apache.org/foundation/voting.html";>Votes</a>
are used to indicate approval or disapproval of something.</strong>
@@ -259,7 +259,7 @@
<p>You are encouraged to use an informal voting model to take a quick poll or
to wrap up a discussion, whether you are a committer yet or not. These votes
are informal and can be initiated by anyone. Binding votes are only needed for
project-level decision-making.
- <h3 id="approval">3.4. Approval Models</h3>
+<h3 id="approval">3.4. Approval Models</h3>
<p><strong>We use three different approval models for formal voting</strong>:
@@ -286,7 +286,7 @@
<p>For electing a new Chair, the PMC may opt to use <em>Single Transferable
Vote</em> (STV) which comes with its own rules. <a
href="http://steve.apache.org/";>Apache STeVe</a> was specifically designed to
enable this process.
- <h3 id="rtc">3.5. RTC and Vetos</h3>
+<h3 id="rtc">3.5. RTC and Vetos</h3>
<p>Typically, CouchDB uses the <a
href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit";>Review-Then-Commit</a>
(<em>RTC</em>) model of code collaboration. RTC allows work to proceed on
separate feature or bugfix branches, and requires at least one other developer
to review and approve the changes before they are committed to a release
branch. A release branch is any branch that a release might be prepared from,
such as <code>master</code>, <code>1.6.x</code>, and so on. Notifications of
these changes are sent to <a
href="https://mail-archives.apache.org/mod_mbox/couchdb-commits/";>the commits
mailing list</a>. It is expected that the rest of the community is regularly
reviewing these changes.
@@ -306,7 +306,7 @@
<p>If the discussion did not reach consensus, Alice could challenge the
validity of Bob's justification. At that point, the PMC would vote on the
issue. If the PMC found that the justification was valid, Alice would have to
revert the change or petition Bob to withdraw the veto. If the PMC found the
justification invalid, the veto is null and void.
- <h3 id="types">3.6. Decision Types</h3>
+<h3 id="types">3.6. Decision Types</h3>
<p><strong>This section describes the various decision types and the rules
that apply to them.</strong></p>
@@ -453,9 +453,9 @@
</tr>
</table>
- <h2 id="other">4. Other Topics</h2>
+<h2 id="other">4. Other Topics</h2>
- <h3 id="tags">4.1. Subject Tags</h3>
+<h3 id="tags">4.1. Subject Tags</h3>
<p><strong>A subject tag is a string like "[TAG]" that appears at the start of
an email subject. We use these to communicate the type of message being
sent.</strong>
