couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nsla...@apache.org
Subject svn commit: r1615241 - in /couchdb/site: bylaws.v1.html bylaws.v2.html
Date Fri, 01 Aug 2014 21:48:24 GMT
Author: nslater
Date: Fri Aug  1 21:48:23 2014
New Revision: 1615241

URL: http://svn.apache.org/r1615241
Log:
Add id attributes to headings

Modified:
    couchdb/site/bylaws.v1.html
    couchdb/site/bylaws.v2.html

Modified: couchdb/site/bylaws.v1.html
URL: http://svn.apache.org/viewvc/couchdb/site/bylaws.v1.html?rev=1615241&r1=1615240&r2=1615241&view=diff
==============================================================================
--- couchdb/site/bylaws.v1.html (original)
+++ couchdb/site/bylaws.v1.html Fri Aug  1 21:48:23 2014
@@ -3,9 +3,9 @@
 <body>
 <p>
 <p><em>These bylaws were officially adopted by the CouchDB PMC as of 2014-07-27
23:59 UTC.</em>
-<h1>Table of Contents</h1>
-<p>TODO
-<h1>1. Introduction</h1>
+<h1 id="toc">Table of Contents</h1>
+<p>TODO<a href="#foo">df</a>
+<h1 id="intro">1. Introduction</h1>
 <p>This document defines the bylaws under which the Apache CouchDB project operates.
It defines the roles and responsibilities within the project, who may vote, how voting works,
how conflicts are resolved, and voting rules for specific decision types.
 <p>This document is written for anyone who wishes to participate in the project. <strong>If
this is your first time through this document, read this introduction, then read all the bolded
text</strong> <strong>for a summary of the bylaws.</strong> Then, as you
need more detail, read past the bolded text for an expanded explanation.
 <p>CouchDB is a project of the <em>Apache Software Foundation</em> (ASF).
Apache CouchDB, CouchDB, and the CouchDB logo are trademarks of the ASF. The project resources
are licensed to the public under the <a href="http://www.apache.org/licenses/LICENSE-2.0.html">Apache
License 2.0</a>. Releases are made in the form of official signed source code archives.
The <a href="https://www.apache.org/foundation/faq.html">ASF FAQ</a> explains
the operation and background of the Foundation.
@@ -21,21 +21,21 @@
 <p>The direction of the project and the decisions we make are up to you. If you are
participating on <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">the mailing
lists</a> you have the right to make decisions. All decisions about the project are
taken on the mailing lists. There are no lead developers, nor is there any one person in charge.
 <p>Anyone can subscribe to the public mailing lists, and in fact, you are encouraged
to do so. The development mailing list is not just for developers, for instance. It is for
anyone who is interested in the development of the project. Everybody's voice is welcome.
 <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.
-<h1>2. Roles and Responsibilities</h1>
+<h1 id="roles">2. Roles and Responsibilities</h1>
 <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>
 <p>Your role is bestowed on you by your peers in recognition of your past contributions
to the project and your position of trust within the community. It is not tied to your job,
your current employer, or your current activity level. We are interested in you as an individual
and we understand that your interactions with the project may change over time.
 <p>Roles are never rescinded because of inactivity, unless that inactivity is causing
a problem for the project. Fortunately, our decision making process means that inactivity
is very rarely a problem. Roles will be rescinded if the <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-ProjectBylaws(WIP)-2.4.ProjectManagementCommittee">Project
Management Committee</a> (or <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-ProjectBylaws(WIP)-2.4.ProjectManagementCommittee">PMC</a>,
see 2.4. below) believes the individual is no longer able to responsibly discharge the duty
of the role.
 <p>We understand that you have many roles in life. We use a hat metaphor to talk about
these roles. For instance, you might have your work hat as well as several ASF hats. We expect
you to know when to wear the appropriate hat, and to comport yourself in a manner befitting
the interests of the Foundation when interacting with the project. Failure to do this is a
serious dereliction of duty.
 <p>Sometimes it is a good idea to tell people which hat you are wearing. For instance,
the PMC Chair might start an informal email by stating they are not wearing the PMC Chair's
hat, just to be clear about how the statements ought to be interpreted.
 <p>We expect you to act in good faith. This is very important for a community that
depends so heavily on trust.
-<h2>2.1. Users</h2>
+<h2 id="users">2.1. Users</h2>
 <p><strong>The most important participants in the project are people who use
our software.</strong>
 <p>Users can participate by talking about the project, providing feedback, and helping
others. This can be done at the ASF or elsewhere, and includes being active on <a href="https://mail-archives.apache.org/mod_mbox/couchdb-user/">the
user mailing list</a>, third-party support forums, blogs, and social media. Users who
participate in this way automatically become contributors.
-<h2>2.2. Contributors</h2>
+<h2 id="contributors">2.2. Contributors</h2>
 <p><strong>A contributor is someone who makes contributions to the community,
project, documentation, or code.</strong>
 <p>There is no special requirement to become a contributor. If you have a great idea
for the project, you can get to work immediately. There is no need to ask permission. Most
things can be accomplished by contributors with no special privileges or status on the project.
Assistance can be provided if you need access to project resources to get your work done.
 <p>A contributor who makes sustained contributions to the project may be invited to
become a committer.
-<h2>2.3. Committers</h2>
+<h2 id="committers">2.3. Committers</h2>
 <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>
 <p>We recognise commitment in many different areas. These include, but are not limited
to:
 <ul>
@@ -50,7 +50,7 @@
 <p>All committers are required to have a signed <em>Individual Contributor License
Agreement</em> (ICLA) on file. There is an <a href="http://www.apache.org/dev/committers.html">ASF
FAQ</a> which provides more details about the requirements at the Foundation level.
 <p>Committers are expected to work cooperatively and to have good social skills. This
is more important than any other sort of skill. Our committers make up the bulk of our active
community, and as such, we rely on them to help us build and maintain that community.
 <p>A committer who makes a sustained contribution to the project may be invited to
become a <em>Project Management Committee</em> (PMC) member.
-<h2>2.4. Project Management Committee</h2>
+<h2 id="pmc">2.4. Project Management Committee</h2>
 <p><strong>The <em>Project Management Committee</em> (PMC) is responsible
for the management of the project.</strong>
 <p>At the most basic level, the role of the PMC is oversight. The PMC must ensure that
all relevant bylaws , policies, and procedures  are adhered to. These exist at the Foundation-level
and the project-level. See the <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+affairs">project
affairs</a> page for more information.
 <p>Beyond this requirement, the primary goal of the PMC is to invest in the long term
wellbeing of the community. For this reason, one of the most basic tasks of the PMC is the
recruitment and management of project contributors. We believe that the size, diversity, and
health of the community is essential for the quality, stability, and robustness of project
and it's social structures.
@@ -65,16 +65,16 @@
 <li>Press and analyst relations</ul>
 <p>PMC members are held to a much higher standard than regular community members. This
includes strict hat wearing, equitable decision making, and exemplary conduct. People look
to PMC members for cues about how to behave. It is important that all PMC members understand
the responsibility that they bear, and that they are individually committed to improving themselves
and the project.
 <p>While security issues and release management are worked by the PMC, the PMC typically
delegates responsibility to the CouchDB committers.
-<h2>2.5. Chair</h2>
+<h2 id="chair">2.5. Chair</h2>
 <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.
 <p>The Chair is elected by the PMC but appointed by the ASF Board via a Board resolution.
The Chair is an officer of the Apache Software Foundation (with an official title of <em>Vice
President, Apache CouchDB</em>) and has primary responsibility to the Board for the
management of the project. The Chair is the eyes and ears of the Board, and reports quarterly
on developments within the project.
 <p>The chair has primary responsibility to the Board, and has the power to establish
rules and procedures for the day to day management of the communities for which the PMC is
responsible, including the composition of the PMC itself.
 <p>Remember that, as in any meeting, the chair is a facilitator and their role within
the PMC is to ensure that everyone has a chance to be heard and to enable meetings to flow
smoothly. There is no concept of "leader" in the Apache way.
 <p>If the current Chair resigns, or the term of the Chair expires, the PMC will hold
a Chair election.
 <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.
-<h2>2.6. Board of Directors</h2>
+<h2 id="board">2.6. Board of Directors</h2>
 <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>.
-<h1>3. Decision Making</h1>
+<h1 id="decisions">3. Decision Making</h1>
 <p>This section explains our approach to decision making and the formal structures
we have in place to make this as easy as possible.
 <p><strong>In descending order of preference, we prefer that decisions are made
via:</strong>
 <ul>
@@ -85,7 +85,7 @@
 <p>All decision making must happen on <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">the
mailing lists</a>. Any discussion that takes place away from the lists (for example
on IRC or in person) must be brought to the lists before anything can be decided. We have
a saying: if it's not on the lists, it didn't happen. We take this approach so that the greatest
amount of people have a chance to participate.
 <p>Decisions should be made on the mailing list associated with the decision. For example,
marketing decisions happen on <a href="https://mail-archives.apache.org/mod_mbox/couchdb-marketing/">the
marketing list</a>. By default, anything without a specific list should be done in public
on the main development list. Anything that needs to be private will be done on the private
list.
 <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.
-<h2>3.1. Lazy Consensus</h2>
+<h2 id="lazy">3.1. Lazy Consensus</h2>
 <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.</strong>
<strong>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 decision types in section
3.6. where lazy consensus is allowed.
 <p>"It's easier to ask forgiveness than it is to get permission." — Grace Hopper
 <p>Most actions are reversible. As long as you do your work in the open, the community
has plenty of opportunities to object. If someone does object, you must be prepared to roll
back your work.
@@ -96,14 +96,14 @@
 <p>For this to work properly, active committers are expected to be paying attention
to the project. Objecting a long time after a change has been made may require large amounts
of additional work to be thrown away or redone.
 <p>Sometimes, you might not be sure what the community would want. If this is the case,
you can post a note to the appropriate <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">mailing
list</a> with an outline of what you intend to do. If nobody objects after 72 hours,
you can safely assume consensus and proceed with your plan.
 <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.
-<h2>3.2. Discussion</h2>
+<h2 id="discussion">3.2. Discussion</h2>
 <p><strong>If lazy consensus fails (i.e. someone objects) you can start a discussion
or you can abandon the proposal.</strong>
 <p>Please try to be respectful of people's time and attention. It is a non-renewable
resource and the only thing we always need more of.
 <p>Proposals should be explained clearly and come with adequate justification. Disagreements
should be constructive and ideally come with alternative proposals. The goal is to reach a
positive outcome for the project, not convince others of your opinion.
 <p>If a proposal is particularly controversial, try making it reversible. Reframe the
proposal as an experiment (either at the project level or the feature level) and identify
a timeline for evaluation along with unambiguous success and failure criteria. These sorts
of proposal are usually much easier to agree on.
 <p>If a clear consensus emerges, you can proceed without a vote. Otherwise, you should
abandon the proposal or move to a vote.
 <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.
-<h2>3.3. Voting</h2>
+<h2 id="voting">3.3. Voting</h2>
 <p><strong><a href="https://www.apache.org/foundation/voting.html">Votes</a>
are used to indicate approval or disapproval of something.</strong>
 <p>We do this by replying with a signed number, usually +1 or -1. Occasionally people
choose to vote with larger amounts (eg. +1000) to indicate strong feelings, or in fractional
amounts (eg. -0.5) to convey support or disagreement without the full weight of a +1 or -1
vote. For the purpose of tallying, all values will be counted as +1, -1, or nothing.
 <p>Here are some example votes, with what they mean, and how they will be counted in
the final vote tally:
@@ -149,7 +149,7 @@
 <p>All formal voting must be done in an email thread with the appropriate <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-4.1.SubjectTags">subject
tag</a>. Formal votes may contain multiple items for approval and these should be clearly
separated. Formal voting is then carried out by replying to the vote mail. Formal votes are
open for a period of at least 72 hours to allow all active voters time to consider the vote.
Votes can be held open longer than this at the discretion of the person who initiated the
vote.
 <p>Votes on <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws#ProjectBylaws-ProjectBylaws(WIP)-3.6.DecisionTypes">PMC
decisions</a> are binding if they are cast by a PMC member. For all other purposes,
votes are binding if they are cast by a committer. However, it is important to remember that
all participants on a list get a vote. And you are encouraged to vote, even if your vote is
not binding. This is a good way to get involved in the project and helps to inform the decision-making
process.
 <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.
-<h2>3.4. Approval Models</h2>
+<h2 id="approval">3.4. Approval Models</h2>
 <p><strong>We use four different approval models for formal voting</strong>:
 <ul>
 <li>RTC (see section 3.5)
@@ -167,7 +167,7 @@
 <p>RTC is only ever used in the context of a code review or a pull request, and does
not require a separate vote thread. Each of the other approval models requires a vote thread.
 <p>Which approval model to use is dictated by the table in section 3.6. This is project
policy, and can be changed by amending this document.
 <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.
-<h2>3.5. RTC Approval &amp; Vetos</h2>
+<h2 id="rtc">3.5. RTC Approval &amp; Vetos</h2>
 <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.
 <p><strong>Any change made to </strong>a release branch is a <em>technical
decision</em> of the project. If a committer wants to object to a technical decision,
they have the option of casting a -1 vote. We call this a veto. Vetos can only be made for
technical reasons.  A -1 vote is not considered a veto in any other context. Vetos should
be used sparingly, and only after careful consideration.
 <p>All vetoes must be justified and vetoes without justification are null and void.
The validity of the justification can be challenged and the outcome is decided with a vote.
If the justification is valid, a veto cannot be overruled and stands until withdrawn by the
caster. If you disagree with a veto, you must lobby the person casting the veto to withdraw
their veto. If a veto is not withdrawn, the commit must be reverted in a timely manner.
@@ -179,7 +179,7 @@
 <li>A discussion ensues, leading to consensus
 <li>Alice reverts the change</ul>
 <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.
-<h2>3.6. Decision Types</h2>
+<h2 id="types">3.6. Decision Types</h2>
 <p><strong>This section describes the various decision types and the rules that
apply to them.</strong>
 <table>
 <tbody>
@@ -305,8 +305,8 @@
 <td colspan="1">No
 <td colspan="1">PMC members
 <td colspan="1">No</table>
-<h1>4. Other Topics</h1>
-<h2>4.1. Subject Tags</h2>
+<h1 id="other">4. Other Topics</h1>
+<h2 id="tags">4.1. Subject Tags</h2>
 <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>
 <p>If a VOTE or PROPOSAL thread is started without the requisite tag, its validity
can be challenged. Every other tag is optional.
 <p>We have agreed on the following tags, but you are free to coin your own.

Modified: couchdb/site/bylaws.v2.html
URL: http://svn.apache.org/viewvc/couchdb/site/bylaws.v2.html?rev=1615241&r1=1615240&r2=1615241&view=diff
==============================================================================
--- couchdb/site/bylaws.v2.html (original)
+++ couchdb/site/bylaws.v2.html Fri Aug  1 21:48:23 2014
@@ -3,9 +3,9 @@
 <body>
 <p>
 <p><em>These bylaws were officially adopted by the CouchDB PMC as of 2014-07-27
23:59 UTC and last modified on 2014-07-31 14:00 UTC.</em>
-<h1>Table of Contents</h1>
+<h1 id="toc">Table of Contents</h1>
 <p>TODO
-<h1>1. Introduction</h1>
+<h1 id="intro">1. Introduction</h1>
 <p>This document defines the bylaws under which the Apache CouchDB project operates.
It defines the <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-2.RolesandResponsibilities">roles
and responsibilities</a> within the project, who may vote, how <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.3.Voting">voting</a>
works, how conflicts are resolved, and voting rules for specific <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">decision
types</a>.
 <p>This document is written for anyone who wishes to participate in the project. <strong>If
this is your first time through this document, read this introduction, then read all the bolded
text</strong> <strong>for a summary of the bylaws.</strong> Then, as you
need more detail, read past the bolded text for an expanded explanation.
 <p>CouchDB is a project of the <em>Apache Software Foundation</em> (ASF).
Apache CouchDB, CouchDB, and the CouchDB logo are trademarks of the ASF. The project resources
are licensed to the public under the <a href="http://www.apache.org/licenses/LICENSE-2.0.html">Apache
License 2.0</a>. Releases are made in the form of official signed source code archives.
The <a href="https://www.apache.org/foundation/faq.html">ASF FAQ</a> explains
the operation and background of the Foundation.
@@ -22,21 +22,21 @@
 <p>The direction of the project and the decisions we make are up to you. If you are
participating on <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">the mailing
lists</a> you have the right to make decisions. All decisions about the project are
taken on the mailing lists. There are no lead developers, nor is there any one person in charge.
 <p>Anyone can subscribe to the public mailing lists, and in fact, you are encouraged
to do so. The development mailing list is not just for developers, for instance. It is for
anyone who is interested in the development of the project. Everybody's voice is welcome.
 <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.
-<h1>2. Roles and Responsibilities</h1>
+<h1 id="roles">2. Roles and Responsibilities</h1>
 <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>
 <p>Your role is bestowed on you by your peers in recognition of your past contributions
to the project and your position of trust within the community. It is not tied to your job,
your current employer, or your current activity level. We are interested in you as an individual
and we understand that your interactions with the project may change over time.
 <p>Roles are never rescinded because of inactivity, unless that inactivity is causing
a problem for the project. Fortunately, our decision making process means that inactivity
is very rarely a problem. Roles will be rescinded if the <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-2.4.ProjectManagementCommittee">Project
Management Committee</a> (or <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-2.4.ProjectManagementCommittee">PMC</a>,
see 2.4. below) believes the individual is no longer able to responsibly discharge the duty
of the role.
 <p>We understand that you have many roles in life. We use a hat metaphor to talk about
these roles. For instance, you might have your work hat as well as several ASF hats. We expect
you to know when to wear the appropriate hat, and to comport yourself in a manner befitting
the interests of the Foundation when interacting with the project. Failure to do this is a
serious dereliction of duty.
 <p>Sometimes it is a good idea to tell people which hat you are wearing. For instance,
the PMC Chair might start an informal email by stating they are not wearing the PMC Chair's
hat, just to be clear about how the statements ought to be interpreted.
 <p>We expect you to act in good faith. This is very important for a community that
depends so heavily on trust.
-<h2>2.1. Users</h2>
+<h2 id="users">2.1. Users</h2>
 <p><strong>The most important participants in the project are people who use
our software.</strong>
 <p>Users can participate by talking about the project, providing feedback, and helping
others. This can be done at the ASF or elsewhere, and includes being active on <a href="https://mail-archives.apache.org/mod_mbox/couchdb-user/">the
user mailing list</a>, third-party support forums, blogs, and social media. Users who
participate in this way automatically become contributors.
-<h2>2.2. Contributors</h2>
+<h2 id="contributors">2.2. Contributors</h2>
 <p><strong>A contributor is someone who makes contributions to the community,
project, documentation, or code.</strong>
 <p>There is no special requirement to become a contributor. If you have a great idea
for the project, you can get to work immediately. There is no need to ask permission. Most
things can be accomplished by contributors with no special privileges or status on the project.
Assistance can be provided if you need access to project resources to get your work done.
 <p>A contributor who makes sustained contributions to the project may be invited to
become a committer.
-<h2>2.3. Committers</h2>
+<h2 id="committers">2.3. Committers</h2>
 <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>
 <p>We recognise commitment in many different areas. These include, but are not limited
to:
 <ul>
@@ -51,7 +51,7 @@
 <p>All committers are required to have a signed <em>Individual Contributor License
Agreement</em> (ICLA) on file. There is an <a href="http://www.apache.org/dev/committers.html">ASF
FAQ</a> which provides more details about the requirements at the Foundation level.
 <p>Committers are expected to work cooperatively and to have good social skills. This
is more important than any other sort of skill. Our committers make up the bulk of our active
community, and as such, we rely on them to help us build and maintain that community.
 <p>A committer who makes a sustained contribution to the project may be invited to
become a <em>Project Management Committee</em> (PMC) member.
-<h2>2.4. Project Management Committee</h2>
+<h2 id="pmc">2.4. Project Management Committee</h2>
 <p><strong>The <em>Project Management Committee</em> (PMC) is responsible
for the management of the project.</strong>
 <p>At the most basic level, the role of the PMC is oversight. The PMC must ensure that
all relevant bylaws , policies, and procedures  are adhered to. These exist at the Foundation-level
and the project-level. See the <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+affairs">project
affairs</a> page for more information.
 <p>Beyond this requirement, the primary goal of the PMC is to invest in the long term
wellbeing of the community. For this reason, one of the most basic tasks of the PMC is the
recruitment and management of project contributors. We believe that the size, diversity, and
health of the community is essential for the quality, stability, and robustness of project
and its social structures.
@@ -66,16 +66,16 @@
 <li>Press and analyst relations</ul>
 <p>PMC members are held to a much higher standard than regular community members. This
includes strict hat wearing, equitable decision making, and exemplary conduct. People look
to PMC members for cues about how to behave. It is important that all PMC members understand
the responsibility that they bear, and that they are individually committed to improving themselves
and the project.
 <p>While security issues and release management are the responsibility of the PMC,
the PMC typically delegates this to committers.
-<h2>2.5. Chair</h2>
+<h2 id="chair">2.5. Chair</h2>
 <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.
 <p>The Chair is elected by the PMC but appointed by the ASF Board via a Board resolution.
The Chair is an officer of the Apache Software Foundation (with an official title of <em>Vice
President, Apache CouchDB</em>) and has primary responsibility to the Board for the
management of the project. The Chair is the eyes and ears of the Board, and reports quarterly
on developments within the project.
 <p>The chair has primary responsibility to the Board, and has the power to establish
rules and procedures for the day to day management of the communities for which the PMC is
responsible, including the composition of the PMC itself.
 <p>Remember that, as in any meeting, the Chair is a facilitator and their role within
the PMC is to ensure that everyone has a chance to be heard and to enable meetings to flow
smoothly.
 <p>If the current Chair resigns, or the term of the Chair expires, the PMC will hold
a Chair election.
 <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.
-<h2>2.6. Board of Directors</h2>
+<h2 id="board">2.6. Board of Directors</h2>
 <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>.
-<h1>3. Decision Making</h1>
+<h1 id="decisions">3. Decision Making</h1>
 <p>This section explains our approach to decision making and the formal structures
we have in place to make this as easy as possible.
 <p><strong>In descending order of preference, we prefer that decisions are made
via:</strong>
 <ul>
@@ -86,7 +86,7 @@
 <p>All decision making must happen on <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">the
mailing lists</a>. Any discussion that takes place away from the lists (for example
on IRC or in person) must be brought to the lists before anything can be decided. We have
a saying: if it's not on the lists, it didn't happen. We take this approach so that the greatest
amount of people have a chance to participate.
 <p>Decisions should be made on the mailing list associated with the decision. For example,
marketing decisions happen on <a href="https://mail-archives.apache.org/mod_mbox/couchdb-marketing/">the
marketing list</a>. By default, anything without a specific list should be done in public
on the main development list. Anything that needs to be private will be done on the private
list.
 <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.
-<h2>3.1. Lazy Consensus</h2>
+<h2 id="lazy">3.1. Lazy Consensus</h2>
 <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.</strong>
<strong>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="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">decision
types</a> in section 3.6. where lazy consensus is allowed.
 <p>"It's easier to ask forgiveness than it is to get permission." — Grace Hopper
 <p>Most actions are reversible. As long as you do your work in the open, the community
has plenty of opportunities to object. If someone does object, you must be prepared to roll
back your work.
@@ -97,14 +97,14 @@
 <p>For this to work properly, active committers are expected to be paying attention
to the project. Objecting a long time after a change has been made may require large amounts
of additional work to be thrown away or redone.
 <p>Sometimes, you might not be sure what the community would want. If this is the case,
you can post a note to the appropriate <a href="https://mail-archives.apache.org/mod_mbox/#couchdb">mailing
list</a> with an outline of what you intend to do. If nobody objects after 72 hours,
you can safely assume consensus and proceed with your plan.
 <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.
-<h2>3.2. Discussion</h2>
+<h2 id="discussion">3.2. Discussion</h2>
 <p><strong>If lazy consensus fails (i.e. someone objects) you can start a discussion
or you can abandon the proposal.</strong>
 <p>Please try to be respectful of people's time and attention. It is a non-renewable
resource and the only thing we always need more of.
 <p>Proposals should be explained clearly and come with adequate justification. Disagreements
should be constructive and ideally come with alternative proposals. The goal is to reach a
positive outcome for the project, not convince others of your opinion.
 <p>If a proposal is particularly controversial, try making it reversible. Reframe the
proposal as an experiment (either at the project level or the feature level) and identify
a timeline for evaluation along with unambiguous success and failure criteria. These sorts
of proposal are usually much easier to agree on.
 <p>If a clear consensus emerges, you can proceed without a vote. Otherwise, you should
abandon the proposal or move to a vote.
 <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.
-<h2>3.3. Voting</h2>
+<h2 id="voting">3.3. Voting</h2>
 <p><strong><a href="https://www.apache.org/foundation/voting.html">Votes</a>
are used to indicate approval or disapproval of something.</strong>
 <p>We do this by replying with a signed number, usually +1 or -1. Occasionally people
choose to vote with larger amounts (eg. +1000) to indicate strong feelings, or in fractional
amounts (eg. -0.5) to convey support or disagreement without the full weight of a +1 or -1
vote. For the purpose of tallying, all values will be counted as +1, -1, or nothing.
 <p>Here are some example votes, with what they mean, and how they will be counted in
the final vote tally:
@@ -150,7 +150,7 @@
 <p>All formal voting must be done in an email thread with the appropriate <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-4.1.SubjectTags">subject
tag</a>. Formal votes may contain multiple items for approval and these should be clearly
separated. Formal voting is then carried out by replying to the vote mail. Formal votes are
open for a period of at least 72 hours to allow all active voters time to consider the vote.
Votes can be held open longer than this at the discretion of the person who initiated the
vote.
 <p>Votes on <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">PMC
decisions</a> are binding if they are cast by a PMC member. For all other purposes,
votes are binding if they are cast by a committer. However, it is important to remember that
all participants on a list get a vote. And you are encouraged to vote, even if your vote is
not binding. This is a good way to get involved in the project and helps to inform the decision-making
process.
 <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.
-<h2>3.4. Approval Models</h2>
+<h2 id="approval">3.4. Approval Models</h2>
 <p><strong>We use three different approval models for formal voting</strong>:
 <ul>
 <li>RTC (see section 3.5)
@@ -166,7 +166,7 @@
 <p>A -1 vote is never called a veto except when using the RTC approval model. This
is because a single -1 vote never has the power to block a vote outside of RTC.
 <p>Which approval model to use is dictated by the table in section 3.6. This is project
policy, and can be changed by amending this document.
 <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.
-<h2>3.5. RTC and Vetos</h2>
+<h2 id="rtc">3.5. RTC and Vetos</h2>
 <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.
 <p><strong>Any change made to </strong>a release branch is a <em>technical
decision</em> of the project. If a committer wants to object to a technical decision,
they have the option of casting a -1 vote. We call this a veto. Vetos can only be made for
technical reasons.  A -1 vote is not considered a veto in any other context. Vetos should
be used sparingly, and only after careful consideration.
 <p>All vetoes must be justified and vetoes without justification are null and void.
The validity of the justification can be challenged and the outcome is decided with a vote.
If the justification is valid, a veto cannot be overruled and stands until withdrawn by the
caster. If you disagree with a veto, you must lobby the person casting the veto to withdraw
their veto. If a veto is not withdrawn, the commit must be reverted in a timely manner.
@@ -178,7 +178,7 @@
 <li>A discussion ensues, leading to consensus
 <li>Alice reverts the change</ul>
 <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.
-<h2>3.6. Decision Types</h2>
+<h2 id="types">3.6. Decision Types</h2>
 <p><strong>This section describes the various decision types and the rules that
apply to them.</strong>
 <table>
 <tbody>
@@ -304,8 +304,8 @@
 <td colspan="1">No
 <td colspan="1">PMC members
 <td colspan="1">No</table>
-<h1>4. Other Topics</h1>
-<h2>4.1. Subject Tags</h2>
+<h1 id="other">4. Other Topics</h1>
+<h2 id="tags">4.1. Subject Tags</h2>
 <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>
 <p>Here's what an example subject looks like, using multiple tags:
 <p><code>[VOTE] [REVISED] Official CouchDB bylaws</code>



Mime
View raw message