You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by wo...@apache.org on 2019/02/12 19:01:23 UTC
[couchdb-www] branch rfc-process updated (795974f -> 8ae3a5a)
This is an automated email from the ASF dual-hosted git repository.
wohali pushed a change to branch rfc-process
in repository https://gitbox.apache.org/repos/asf/couchdb-www.git.
discard 795974f Introduce new RFC process, fix mailing list links
new 8ae3a5a Introduce new RFC process, fix mailing list links
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (795974f)
\
N -- N -- N refs/heads/rfc-process (8ae3a5a)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
bylaws.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[couchdb-www] 01/01: Introduce new RFC process,
fix mailing list links
Posted by wo...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
wohali pushed a commit to branch rfc-process
in repository https://gitbox.apache.org/repos/asf/couchdb-www.git
commit 8ae3a5a230b1717d7affe23625eeb288635aa542
Author: Joan Touzet <jo...@atypical.net>
AuthorDate: Tue Feb 12 13:55:08 2019 -0500
Introduce new RFC process, fix mailing list links
---
bylaws.html | 66 ++++++++++++++++++++++++++++++++++++++++++++++---------------
1 file changed, 50 insertions(+), 16 deletions(-)
diff --git a/bylaws.html b/bylaws.html
index 77ad2c0..d1feba7 100644
--- a/bylaws.html
+++ b/bylaws.html
@@ -8,7 +8,8 @@
<h1>CouchDB Bylaws</h1>
-<p><em>This document was officially adopted by the CouchDB PMC as of 31 July 2014.</em>
+<p><em>This document was officially adopted by the CouchDB PMC as of 31 July 2014.</em></p>
+<p>A full changelog is available <a href="https://github.com/apache/couchdb-www/commits/asf-site/bylaws.html">on GitHub</a>.</p>
<h2>Table of Contents</h2>
@@ -35,7 +36,7 @@
<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>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>The direction of the project and the decisions we make are up to you. If you are participating on <a href="https://couchdb.apache.org/#mailing-lists">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.
@@ -59,7 +60,7 @@
<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.
+<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://lists.apache.org/list.html?user@couchdb.apache.org">the user mailing list</a>, third-party support forums, blogs, and social media. Users who participate in this way automatically become contributors.
<h3 id="contributors">2.2. Contributors</h3>
@@ -152,9 +153,9 @@
<p>Our goal is to build a community of trust, reduce mailing list traffic, and deal with disagreements swiftly when they occur.
-<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>All decision making must happen on <a href="https://couchdb.apache.org/#mailing-lists">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>Decisions should be made on the mailing list associated with the decision. For example, marketing decisions happen on <a href="https://lists.apache.org/list.html?marketing@couchdb.apache.org">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.
@@ -177,7 +178,7 @@
<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>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://couchdb.apache.org/#mailing-lists">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.
@@ -251,7 +252,7 @@
</tr>
</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="#decisions">decision type</a>. More detail on <a href="#approval">approval models</a>, <a href="#rtc">vetos</a>, and <a href="types">decision types</a> is available in sections 3.4, 3.5., and 3.6 respectively.
+<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="#decisions">decision type</a>. More detail on <a href="#approval">approval models</a>, <a href="#rtc">RTC and technical vetos</a>, <a href="#rfc">RFCs</a>, <a href="#api">API changes and deprecations</a> and <a href="types">decision types</a> is available in the following sections.
<p>All formal voting must be done in an email thread with the appropriate <a href="#tags">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.
@@ -261,7 +262,7 @@
<h3 id="approval">3.4. Approval Models</h3>
-<p><strong>We use three different approval models for formal voting</strong>:
+<p><strong>We use four different approval models for formal voting</strong>:
<ul>
<li>RTC (see section 3.5)
@@ -272,6 +273,11 @@
<ul>
<li>Requires three binding +1 votes and more binding +1 votes than binding -1 votes
</ul>
+ <li>Qualified lazy majority
+ <ul>
+ <li>Requires three binding +1 votes and more binding +1 votes than binding -1 votes
+ <li>In addition, at least one binding +1 vote must be from an individual not directly affiliated with the proposer's employer (if applicable)
+ </ul>
<li>Lazy 2/3 majority
<ul>
<li>Requires three binding +1 votes and twice as many binding +1 votes as binding -1 votes
@@ -280,17 +286,17 @@
<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>Qualified lazy majority is only used for the <a href="#rfc">RFC process</a>.</p>
+
<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.
-<h3 id="rtc">3.5. Review-Then-Commit, API Changes and Technical Vetos</h3>
+<h3 id="rtc">3.5. Review-Then-Commit and Technical Vetos</h3>
-<p>Typically, CouchDB uses the <a href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit">Review-Then-Commit</a> (<em>RTC</em>) model of code collaboration. RTC allows work to proceed on separate feature or bugfix branches, and requires at least one other developer to review and approve the changes before they are committed to a release branch. A release branch is any branch that a release might be prepared from, such as <code>master</code>, <code>1.6.x</code>, and so on. [...]
-
-<p>Whenever a change is proposed to a release branch or <code>master</code> that removes or changes an existing HTTP API endpoint in a way that breaks backwards compatibility with a released version of CouchDB, the proposed change <strong><em>must</em> be announced on the developer mailing list, and a minimum of a <a href="#lazy">lazy consensus</a> decision is required.</strong> This policy is not intended to preserve bugs in HTTP API endpoints across released versions of CouchDB in perp [...]
+<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. [...]
<p><strong>Any change made to a release branch or to the <code>master</code> 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.</strong> 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.
@@ -308,6 +314,24 @@
<p>If the discussion did not reach consensus, Alice could challenge the validity of Bob's justification. At that point, the PMC would vote on the issue. If the PMC found that the justification was valid, Alice would have to revert the change or petition Bob to withdraw the veto. If the PMC found the justification invalid, the veto is null and void.
+<h3 id="rfc">3.6 Request For Comment (RFC) process</h3>
+
+For major changes to the fuctionality of CouchDB, a Request For Comment (RFC) process has been established. The intent of an RFC is to ensure sufficient public discussion has occurred on the design of new features, that the proposal is adequately captured in a summary document, and that there is community acceptance of the proposal. The completed RFC template for the proposal then becomes the basis for the new functionality's documentation.
+
+The process is:
+
+ <ul>
+ <li>Start a [DISCUSS] thread on <a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the developer mailing list</a>. Discuss your proposal in detail, including which modules/applications are affected, any HTTP API additions and deprecations, and security issues.</li>
+ <li>When there is consensus on the approach from the community, <a href="https://s.apache.org/CouchDB-RFC">file an RFC</a> and notify the developer mailing list of the RFC. This starts the <strong>vote</strong>. (If you do not have a GitHub account, email the completed <a href="https://raw.githubusercontent.com/apache/couchdb/master/.github/ISSUE_TEMPLATE/rfc.md ">template</a> to the developer mailing list.)</li>
+ <li>Hold the vote according to the <em>qualified lazy majority process</em>: at least 3 +1 votes, more +1 than -1 votes, and at least one +1 vote must be from someone not directly affiliated with the proposer's employer.</li>
+ </ul>
+
+<h3 id="api">3.7 API changes and deprecations</h3>
+
+<p>Whenever a change is proposed to a release branch or <code>master</code> that removes or changes an existing HTTP API endpoint in a way that breaks backwards compatibility with a released version of CouchDB, the proposed change <strong><em>must</em> be announced on <a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the developer mailing list</a>, and a minimum of a <a href="#lazy">lazy consensus</a> decision is required.</strong>
+
+<p>This policy is not intended to preserve bugs in HTTP API endpoints across released versions of CouchDB in perpetuity, nor shall it be used to assert consistency of undocumented, implementation-specific behaviour across major releases. Additions of new endpoints that fall short of the need for an RFC, or changes that do not affect backwards compatibility, do not require this notification and process, but announcement to the developer mailing list is still strongly encouraged.</p>
+
<h3 id="types">3.6. Decision Types</h3>
<p><strong>This section describes the various decision types and the rules that apply to them.</strong></p>
@@ -326,7 +350,7 @@
<tr>
<td>Technical decision
<td>A technical decision is any change made to a release branch.
- <td><a href="https://mail-archives.apache.org/mod_mbox/couchdb-commits/">Commits list</a>
+ <td><a href="https://lists.apache.org/list.html?commits@couchdb.apache.org">Commits list</a>
<td>Allowed for trivial changes
<td>RTC
<td>No
@@ -334,6 +358,16 @@
<td> Yes
</tr>
<tr>
+ <td>Request For Comments (RFC) decision
+ <td>A decision on a specific proposal to alter CouchDB in a significant way.
+ <td><a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main development list</a>
+ <td>No
+ <td>Qualified lazy majority
+ <td>No
+ <td>Committers
+ <td>No
+ </tr>
+ <tr>
<td>Non-technical decision
<td>
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.
@@ -354,7 +388,7 @@
<br>
<br>
A veto is only valid when it is justified with a sound technical argument.
- <td><a href="https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main development list</a>
+ <td><a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main development list</a>
<td>No
<td>Lazy 2/3 majority
<td>No
@@ -368,7 +402,7 @@
<br>
<br>
Release candidates can be prepared by anyone.
- <td><a href="https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main development list</a>
+ <td><a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main development list</a>
<td>No
<td>Lazy majority
<td>No
@@ -446,7 +480,7 @@
<tr>
<td>Create or amend official document
<td>Create or amend any document marked as official.
- <td><a href="https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main development list</a>
+ <td><a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main development list</a>
<td>No
<td>Lazy 2/3 majority
<td>No