couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nsla...@apache.org
Subject svn commit: r1618509 - /couchdb/site/bylaws.html
Date Sun, 17 Aug 2014 19:19:13 GMT
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>
 



Mime
View raw message