couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [VOTE] Bylaws change: Establish a Request For Comments (RFC) process for major new contribution (revised)
Date Wed, 06 Mar 2019 09:41:30 GMT
+1

> On 5. Mar 2019, at 21:18, Joan Touzet <wohali@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?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.
> 
> @@ -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?commits@couchdb.apache.org">the
commits mailing list</a>, with GitHub discussion appearing on <a href="https://lists.apache.org/list.html?notifications@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?commits@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/


Mime
View raw message