+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/
>
