You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by ns...@apache.org on 2014/08/17 21:19:13 UTC
svn commit: r1618509 - /couchdb/site/bylaws.html
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>