+1 On Wed, Mar 6, 2019 at 1:36 PM Andy Wenk <andyw...@apache.org> wrote:
> +1 > > > On 6. Mar 2019, at 10:41, Jan Lehnardt <j...@apache.org> wrote: > > > > +1 > > > >> On 5. Mar 2019, at 21:18, Joan Touzet <woh...@apache.org> wrote: > >> > >> (Revised: The Reply-To field on the last email was incorrect. I am > >> also including the diff of the proposed changes to this email per > >> request.) > >> > >> ------------ > >> > >> PMC Members, > >> > >> This is a VOTE to create or amend our official documents. > >> > >> It establishes a new Request For Comments (RFC) process through which > >> all major changes to Apache CouchDB must pass. > >> > >> This includes modifying the Bylaws to explain the process, as well as > >> adding the new RFC template. > >> > >> There are also minor changes proposed to the Bylaws to improve links to > >> external information resources, such as the new Pony Mail mailing list > >> interface. > >> > >> The git branch with the proposed changes is here: > >> > >> https://github.com/apache/couchdb-www/compare/asf-site...add-rfc > >> > >> Two commits have been used to make it clearer which changes are purely > >> cosmetic, and which directly affect the text of the bylaws. > >> > >> An important note: this vote explicitly excludes the mechanics of the > >> process in GitHub, focusing only on the proposal and voting procedures. > >> (Whether we store the RFCs in our main tree or the docs tree, and > >> whether we use issues or PRs for them don't have to go in the bylaws.) > >> > >> Per our process, this vote occurs on the Main development list (dev@), > >> and requires a Lazy 2/3 majority, meaning it requires three binding +1 > >> votes and twice as many binding +1 votes as binding -1 votes. Only PMC > >> Members can vote on this issue, and no veto is allowed. > >> > >> This vote will run for one week, ending on 12 March 2019 23:59 UTC. > >> > >> -Joan > >> > >> > >> --------------------------------------------------- > >> > >> diff --git a/bylaws.html b/bylaws.html > >> index 77ad2c0..4aea136 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?u...@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?market...@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. > >> > >> @@ -286,11 +287,9 @@ > >> > >> <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. > 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>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 > perpetuity, nor shall it be used to assert consistency of undocumented, > implementation-specific behaviour across major releases. Additions of new > endpoints, 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> > >> +<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://lists.apache.org/list.html?comm...@couchdb.apache.org";>the > commits mailing list</a>, with GitHub discussion appearing on <a href=" > https://lists.apache.org/list.html?notificati...@couchdb.apache.org";>the > notifications mailing list</a>. It is expected that the rest of the > community is regularly reviewing these changes. > >> > >> <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,7 +307,25 @@ > >> > >> <p>If the discussion did not reach consensus, Alice could challenge the > validity of Bob's justification. At that point, the PMC would vote on the > issue. If the PMC found that the justification was valid, Alice would have > to revert the change or petition Bob to withdraw the veto. If the PMC found > the justification invalid, the veto is null and void. > >> > >> -<h3 id="types">3.6. Decision Types</h3> > >> +<h3 id="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";>complete the RFC template</a> and > work through any final revisions to the document, with the support of the > developer mailing list.</li> > >> + <li>Start the RFC <strong>vote</strong> on the developer mailing > list. Hold the vote according to the <em>lazy majority process</em>: at > least 3 +1 votes, and more binding +1 than binding -1 votes.</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.8. Decision Types</h3> > >> > >> <p><strong>This section describes the various decision types and the > rules that apply to them.</strong></p> > >> > >> @@ -326,12 +343,22 @@ > >> <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?comm...@couchdb.apache.org";>Commits > list</a> > >> <td>Allowed for trivial changes > >> <td>RTC > >> <td>No > >> <td>Committers > >> - <td> Yes > >> + <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>Lazy majority > >> + <td>No > >> + <td>Committers > >> + <td>No > >> </tr> > >> <tr> > >> <td>Non-technical decision > >> @@ -354,7 +381,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 +395,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 +473,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 > > > > -- > > Professional Support for Apache CouchDB: > > https://neighbourhood.ie/couchdb-support/ > > > >
