You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by ns...@apache.org on 2014/08/01 23:18:03 UTC
svn commit: r1615233 - in /couchdb/site: bylaws.v1.html bylaws.v2.html
Author: nslater
Date: Fri Aug 1 21:18:03 2014
New Revision: 1615233
URL: http://svn.apache.org/r1615233
Log:
Remove spans
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=1615233&r1=1615232&r2=1615233&view=diff
==============================================================================
--- couchdb/site/bylaws.v1.html (original)
+++ couchdb/site/bylaws.v1.html Fri Aug 1 21:18:03 2014
@@ -6,7 +6,7 @@
<h1>Table of Contents</h1>
<p>TODO
<h1>1. Introduction</h1>
-<p>This document defines the bylaws under which the Apache CouchDB project operates. It defines the roles and responsibilities <span>within</span> the project, who may vote, how voting works, how conflicts are resolved, and voting rules for specific decision types.
+<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.
<p>CouchDB operates under a set of common principles known collectively as <a href="https://www.apache.org/foundation/how-it-works.html">the Apache Way</a>:
@@ -23,14 +23,14 @@
<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>
<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><span><span>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.</span></span>
-<p><span><span>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.</span></span>
-<p><span>We understand that you have many roles in life. We use a hat metaphor to talk about these roles. For instance, y</span><span>ou might have your work hat as well as several ASF hats. </span><span>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 </span><span>dereliction</span><span> of duty.</span>
-<p><span>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.</span>
-<p><span>We expect you to act in good faith. This is very important for a community that depends so heavily on trust.</span>
+<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>
<p><strong>The most important participants in the project are people who use our software.</strong>
-<p><span>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.</span>
+<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>
<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.
@@ -44,16 +44,16 @@
<li>Documentation (documentation, localisation/internationalisation, etc.)
<li>Code (new features, bug fixing, quality assurance, release management etc.)</ul>
<p>More details are available in <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide">the contributor guide</a>. If any of these things sound interesting to you, we welcome your help.
-<p>The role of committer is mandated at the Foundation level. Unfortunately, the usual definition of that wordâbeing someone who commits codeâcan mean that non-coders are never given binding votes on a project. We think that's a problem. C<span>ontributions come in many shapes and sizes. Indeed, many of those non-code contributions are what the project needs the most.</span>
+<p>The role of committer is mandated at the Foundation level. Unfortunately, the usual definition of that wordâbeing someone who commits codeâcan mean that non-coders are never given binding votes on a project. We think that's a problem. Contributions come in many shapes and sizes. Indeed, many of those non-code contributions are what the project needs the most.
<p>To make this clear, we have chosen to define a committer as someone who is <em>committed</em>. We mean this in the sense of being loyal to the project and its interests. It is a position of trust, not an expectation of activity level. Anyone who is supportive of the community and the project will be considered as a candidate for being a committer.
<p>As a matter of convenience, committers are also given write access to all of the public project infrastructure, including source control repositories, website, issue tracker, wiki, and blog. Access to social media accounts, and other third-party services, will be granted upon request.
-<p><span>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.</span>
-<p><span><span>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</span><span> community.</span></span>
+<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>
<p><strong>The <em>Project Management Committee</em> (PMC) is responsible for the management of the project.</strong>
-<p><span>At the most basic level, the role of the PMC is oversight. The PMC must ensure that all relevant</span> <span>bylaws</span><span> </span><span>,</span> <span>policies, and procedures</span><span> </span> <span><span>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.</span></span>
-<p>Beyond this requirement, the primary goal of the PMC is to invest in the long term wellbeing of the community. <span>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.</span>
+<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.
<p>Actives of the PMC include, but are not limited to:
<ul>
<li>Project governance
@@ -63,17 +63,17 @@
<li>Managing confidentially-reported security issues
<li>Branding and events coordination
<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. <span>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.</span>
-<p><span>While security issues and release management are worked by the PMC, <span><span>the PMC typically delegates responsibility to the CouchDB committers</span></span>.<br></span>
+<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.<br>
<h2>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><span>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.<br></span>
-<h2><span>2.6. Board of Directors</span></h2>
-<p><span><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>.</span>
+<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.<br>
+<h2>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>
<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>
@@ -89,13 +89,13 @@
<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.
-<p><span>Lazy consensus has two effects:</span>
+<p>Lazy consensus has two effects:
<ol>
<li>People are less likely to object for the sake of it
<li>It cuts down on the amount of unnecessary discussion</ol>
<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. <span>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.</span>
+<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>
<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.
@@ -105,7 +105,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.
<h2>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><span>We do this by replying with a signed number, usually +1 or -1. </span><span>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. </span>
+<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:
<table>
<tbody>
@@ -145,9 +145,9 @@
<td colspan="1">-1000
<td colspan="1">"Extremely unhappy with this proposal."
<td colspan="1">-1</table>
-<p>There are three types of voting: informal, formal, and vetos. An informal vote is a quick way to get people's feelings on something. <span>A formal vote, on the other hand, requires an approval model and a decision type. More detail on approval models, vetos and decision types is available in sections 3.4, 3.5., and 3.6.<br></span>
-<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><span>. </span><span>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. </span><span>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.</span>
-<p><span>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.</span>
+<p>There are three types of voting: informal, formal, and vetos. An informal vote is a quick way to get people's feelings on something. A formal vote, on the other hand, requires an approval model and a decision type. More detail on approval models, vetos and decision types is available in sections 3.4, 3.5., and 3.6.<br>
+<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>
<p><strong>We use four different approval models for formal voting</strong>:
@@ -168,16 +168,16 @@
<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>
-<p><span>Typically, CouchDB uses the</span> <a href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit">Review-Then-Commit</a> <span>(</span><em>RTC</em><span>) 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. </span><span>Notifications of these changes are sent to </span><a href="https://mail-archives.apache.org/mod_mbox/couchdb-commits/">the commits mailing list</a><span>. It is expected that the rest of the community is regularly reviewing these changes.</span>
-<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. V<span>etos can only be made for technical reasons. </span><span>A -1 vote is not considered a veto in any other context. Vetos should be used sparingly, and only after careful consideration.</span>
-<p><span><span>All vetoes must be justified and</span><span> v</span><span>etoes without justification are null and void. The validity of the justification can be challenged and the outcome is decided with a vote. </span></span><span><span>If the justification is valid, a</span></span><span><span> veto cannot be overruled and stands until withdrawn by the caster.</span></span><span><span> </span></span><span>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.</span>
-<p><span>Here's how a veto might lead to a code revert:</span>
+<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.
+<p>Here's how a veto might lead to a code revert:
<ul>
-<li><span>Alice commits a change</span>
-<li><span>Bob spots the change and realises that it's going to cause a major problem</span>
-<li><span>Bob replies to the commit email with a -1 vote and a justification</span>
-<li><span>A discussion ensues, leading to consensus</span>
-<li><span>Alice reverts the change</span></ul>
+<li>Alice commits a change
+<li>Bob spots the change and realises that it's going to cause a major problem
+<li>Bob replies to the commit email with a -1 vote and a justification
+<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>
<p><strong>This section describes the various decision types and the rules that apply to them.</strong>
@@ -205,13 +205,13 @@
<tr>
<td>Non-technical decision
<td>
-<p><span>A non-technical decision is any other sort of change, or any sort of decision that falls outside of the other decision types. It is a catch-all decision type.</span>
-<p>Non-technical decisions should normally be <span>made with lazy consensus, or by the</span> entire community using discussion-led consensus-building, and not through formal voting.
+<p>A non-technical decision is any other sort of change, or any sort of decision that falls outside of the other decision types. It is a catch-all decision type.
+<p>Non-technical decisions should normally be made with lazy consensus, or by the entire community using discussion-led consensus-building, and not through formal voting.
<td colspan="1">Whichever mailing list is most appropriate
<td colspan="1">Allowed
<td>Majority approval
<td colspan="1">No
-<td colspan="1"><span>Committers</span>
+<td colspan="1">Committers
<td> No
<tr>
<td colspan="1">Challenge a veto
@@ -253,9 +253,9 @@
<p>Nominations can be made by anyone by emailing <a href="https://mail-search.apache.org/pmc/private-arch/couchdb-private/">the private list</a>.
<td colspan="1"><a href="https://mail-search.apache.org/pmc/private-arch/couchdb-private/">Private list</a>
<td colspan="1">No
-<td colspan="1"><span>Majority approval</span>
+<td colspan="1">Majority approval
<td colspan="1">Yes
-<td colspan="1"><span>PMC members</span>
+<td colspan="1">PMC members
<td colspan="1">No
<tr>
<td colspan="1">Elect Chair
@@ -263,9 +263,9 @@
<p>Elect a new Chair.
<td colspan="1"><a href="https://mail-search.apache.org/pmc/private-arch/couchdb-private/">Private list</a>
<td colspan="1">No
-<td colspan="1"><span>Majority approval or STV</span>
+<td colspan="1">Majority approval or STV
<td colspan="1">Yes
-<td colspan="1"><span>PMC members</span>
+<td colspan="1">PMC members
<td colspan="1">No
<tr>
<td colspan="1">Committer removal
@@ -291,8 +291,8 @@
<td colspan="1">Chair removal
<td colspan="1">Remove the Chair.
<td colspan="1"><a href="https://mail-search.apache.org/pmc/private-arch/couchdb-private/">Private list</a>
-<td colspan="1"><span>No</span>
-<td colspan="1"><span>Lazy 2/3 majority</span>
+<td colspan="1">No
+<td colspan="1">Lazy 2/3 majority
<td colspan="1">Yes
<td colspan="1">PMC members
<td colspan="1">No
Modified: couchdb/site/bylaws.v2.html
URL: http://svn.apache.org/viewvc/couchdb/site/bylaws.v2.html?rev=1615233&r1=1615232&r2=1615233&view=diff
==============================================================================
--- couchdb/site/bylaws.v2.html (original)
+++ couchdb/site/bylaws.v2.html Fri Aug 1 21:18:03 2014
@@ -6,7 +6,7 @@
<h1>Table of Contents</h1>
<p>TODO
<h1>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> <span>within</span> 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 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.
<p>CouchDB operates under a set of common principles known collectively as <a href="https://www.apache.org/foundation/how-it-works.html">the Apache Way</a>:
@@ -17,20 +17,21 @@
<li>Respectful, honest, technical-based interaction
<li>Faithful implementation of standards
<li>Security as a mandatory feature</ul>
-<p>We value the community more than the code. A strong and healthy community should be a fun and rewarding place for everyone involved. Code, and everything else that goes with that code, will be produced by a healthy community over time.
+<p>We value the community more than the code. A strong and healthy community should be a fun and rewarding place for everyone involved. Code, and everything else that goes with that code, will be produced by a healthy community over b
+ time.
<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>
<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><span>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.</span>
-<p><span>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.</span>
-<p><span>We understand that you have many roles in life. We use a hat metaphor to talk about these roles. For instance, y</span><span>ou might have your work hat as well as several ASF hats. </span><span>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 </span><span>dereliction</span><span> of duty.</span>
-<p><span>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.</span>
-<p><span>We expect you to act in good faith. This is very important for a community that depends so heavily on trust.</span>
+<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>
<p><strong>The most important participants in the project are people who use our software.</strong>
-<p><span>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.</span>
+<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>
<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.
@@ -44,17 +45,17 @@
<li>Documentation (documentation, localisation/internationalisation, etc.)
<li>Code (new features, bug fixing, quality assurance, release management etc.)</ul>
<p>More details are available in <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide">the contributor guide</a>. If any of these things sound interesting to you, we welcome your help.
-<p>The role of committer is mandated at the Foundation level. Unfortunately, the usual definition of that wordâbeing someone who commits codeâcan mean that non-coders are never given binding votes on a project. We think that's a problem. C<span>ontributions come in many shapes and sizes. Indeed, many of those non-code contributions are what the project needs the most.</span>
+<p>The role of committer is mandated at the Foundation level. Unfortunately, the usual definition of that wordâbeing someone who commits codeâcan mean that non-coders are never given binding votes on a project. We think that's a problem. Contributions come in many shapes and sizes. Indeed, many of those non-code contributions are what the project needs the most.
<p>To make this clear, we have chosen to define a committer as someone who is <em>committed</em>. We mean this in the sense of being loyal to the project and its interests. It is a position of trust, not an expectation of activity level. Anyone who is supportive of the community and the project will be considered as a candidate for being a committer.
<p>As a matter of convenience, committers are also given write access to all of the public project infrastructure, including source control repositories, website, issue tracker, wiki, and blog. Access to social media accounts, and other third-party services, will be granted upon request.
-<p><span>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.</span>
-<p><span><span>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</span><span> community.</span></span>
+<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>
<p><strong>The <em>Project Management Committee</em> (PMC) is responsible for the management of the project.</strong>
-<p><span>At the most basic level, the role of the PMC is oversight. The PMC must ensure that all relevant </span><span>bylaws</span><span> </span><span>, </span><span>policies, and procedures</span><span> </span><span> 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.</span>
-<p>Beyond this requirement, the primary goal of the PMC is to invest in the long term wellbeing of the community. <span>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.</span>
-<p><span>Activities</span> of the PMC include, but are not limited to:
+<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.
+<p>Activities of the PMC include, but are not limited to:
<ul>
<li>Project governance
<li>Community management
@@ -63,17 +64,17 @@
<li>Managing confidentially-reported security issues
<li>Branding and events coordination
<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. <span>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.</span>
-<p><span>While security issues and release management are the responsibility of the PMC, <span>the PMC typically delegates this to committers</span>.<br></span>
+<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.<br>
<h2>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><span>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.<br></span>
-<h2><span>2.6. Board of Directors</span></h2>
-<p><span><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>.</span>
+<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.<br>
+<h2>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>
<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>
@@ -89,13 +90,13 @@
<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.
-<p><span>Lazy consensus has two effects:</span>
+<p>Lazy consensus has two effects:
<ol>
<li>People are less likely to object for the sake of it
<li>It cuts down on the amount of unnecessary discussion</ol>
<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. <span>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.</span>
+<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>
<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.
@@ -105,7 +106,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.
<h2>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><span>We do this by replying with a signed number, usually +1 or -1. </span><span>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. </span>
+<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:
<table>
<tbody>
@@ -146,8 +147,8 @@
<td colspan="1">"Extremely unhappy with this proposal."
<td colspan="1">-1</table>
<p>There are three types of voting: informal, formal, and vetos. An informal vote is a quick way to get people's feelings on something. A formal vote, on the other hand, requires an approval model and a <a href="https://cwiki.apache.org/confluence/display/COUCHDB/Project+Bylaws" >decision type</a>. More detail on <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.4.ApprovalModels">approval models</a>, <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.5.RTCandVetos">vetos</a>, and <a href="https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=40511017#ProjectBylaws-3.6.DecisionTypes">decision types</a> is available in sections 3.4, 3.5., and 3.6 respectively.
-<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. <span>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.</span>
-<p><span>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.</span>
+<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>
<p><strong>We use three different approval models for formal voting</strong>:
@@ -166,16 +167,16 @@
<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>
-<p><span>Typically, CouchDB uses the </span><a href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit">Review-Then-Commit</a><span> (</span><em>RTC</em><span>) 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. </span><span>Notifications of these changes are sent to </span><a href="https://mail-archives.apache.org/mod_mbox/couchdb-commits/">the commits mailing list</a><span>. It is expected that the rest of the community is regularly reviewing these changes.</span>
-<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. V<span>etos can only be made for technical reasons. </span><span>A -1 vote is not considered a veto in any other context. Vetos should be used sparingly, and only after careful consideration.</span>
-<p><span><span>All vetoes must be justified and</span><span> v</span><span>etoes without justification are null and void. The validity of the justification can be challenged and the outcome is decided with a vote. </span></span><span>If the justification is valid, a</span><span> veto cannot be overruled and stands until withdrawn by the caster.</span><span><span> </span></span><span>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.</span>
-<p><span>Here's how a veto might lead to a code revert:</span>
+<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.
+<p>Here's how a veto might lead to a code revert:
<ul>
-<li><span>Alice commits a change</span>
-<li><span>Bob spots the change and realises that it's going to cause a major problem</span>
-<li><span>Bob replies to the commit email with a -1 vote and a justification</span>
-<li><span>A discussion ensues, leading to consensus</span>
-<li><span>Alice reverts the change</span></ul>
+<li>Alice commits a change
+<li>Bob spots the change and realises that it's going to cause a major problem
+<li>Bob replies to the commit email with a -1 vote and a justification
+<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>
<p><strong>This section describes the various decision types and the rules that apply to them.</strong>
@@ -203,7 +204,7 @@
<tr>
<td>Non-technical decision
<td>
-<p><span>A non-technical decision is any other sort of change, or any sort of decision that falls outside of the other decision types. It is a catch-all decision type.</span>
+<p>A non-technical decision is any other sort of change, or any sort of decision that falls outside of the other decision types. It is a catch-all decision type.
<p>Non-technical decisions should normally be made with lazy consensus, or by the entire community using discussion-led consensus-building, and not through formal voting.
<td colspan="1">Whichever mailing list is most appropriate
<td colspan="1">Allowed