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 & Vetos</h2>
+<h2 id="rtc">3.5. RTC Approval & 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>
