couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@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:25:27 GMT
+1 thanks Joan for working on this

On Wed, Mar 6, 2019 at 10:10 AM Joan Touzet <wohali@apache.org> wrote:

> +1 to my own proposal.
>
> -Joan
>
> ----- Original Message -----
> > From: "Joan Touzet" <wohali@apache.org>
> > To: "CouchDB Developers" <dev@couchdb.apache.org>
> > Sent: Tuesday, 5 March, 2019 3:18:01 PM
> > Subject: [VOTE] Bylaws change: Establish a Request For Comments (RFC)
> process for major new contribution (revised)
> >
> > (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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message