From dev-return-48418-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Wed Mar 6 09:25:42 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id E5F7F180656 for ; Wed, 6 Mar 2019 10:25:41 +0100 (CET) Received: (qmail 75768 invoked by uid 500); 6 Mar 2019 09:25:40 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 75752 invoked by uid 99); 6 Mar 2019 09:25:40 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Mar 2019 09:25:40 +0000 Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 5322134D6 for ; Wed, 6 Mar 2019 09:25:39 +0000 (UTC) Received: by mail-it1-f172.google.com with SMTP id m137so8504092ita.0 for ; Wed, 06 Mar 2019 01:25:39 -0800 (PST) X-Gm-Message-State: APjAAAWhzHfNRkErIWZMft0MJW5QVFOFAYi3BkGQIERCYGgSvhvwcmKA 90ziue5KLQkKlH23NKPIe+hMiOk7IYZ8+zvC4aB4XQ== X-Google-Smtp-Source: APXvYqzGXtaO//opgdYABPCIpME/BRSfebdmUIbN9M4+YoIUjrLNv8dFxZO1st5XEfo0DXoUGCJKB8QZZO9KtjaNP0A= X-Received: by 2002:a02:745:: with SMTP id f66mr3823635jaf.137.1551864338791; Wed, 06 Mar 2019 01:25:38 -0800 (PST) MIME-Version: 1.0 References: <824076780.3467.1551817080792.JavaMail.Joan@BRAIN> <155139218.361.1551859801144.JavaMail.joant@minerva> In-Reply-To: <155139218.361.1551859801144.JavaMail.joant@minerva> From: Garren Smith Date: Wed, 6 Mar 2019 11:25:27 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [VOTE] Bylaws change: Establish a Request For Comments (RFC) process for major new contribution (revised) To: CouchDB Developers , Joan Touzet Content-Type: multipart/alternative; boundary="000000000000a7605a05836992ec" --000000000000a7605a05836992ec Content-Type: text/plain; charset="UTF-8" +1 thanks Joan for working on this On Wed, Mar 6, 2019 at 10:10 AM Joan Touzet wrote: > +1 to my own proposal. > > -Joan > > ----- Original Message ----- > > From: "Joan Touzet" > > To: "CouchDB Developers" > > 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 @@ > > > >

CouchDB Bylaws

> > > > -

This document was officially adopted by the CouchDB PMC as of > > 31 July 2014. > > +

This document was officially adopted by the CouchDB PMC as of > > 31 July 2014.

> > +

A full changelog is available > href="https://github.com/apache/couchdb-www/commits/asf-site/bylaws.html > ">on > > GitHub.

> > > >

Table of Contents

> > > > @@ -35,7 +36,7 @@ > > > >

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. > > > > -

The direction of the project and the decisions we make are up to > > you. If you are participating on > href="https://mail-archives.apache.org/mod_mbox/#couchdb">the > > mailing lists 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. > > +

The direction of the project and the decisions we make are up to > > you. If you are participating on > href="https://couchdb.apache.org/#mailing-lists">the mailing > > lists 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. > > > >

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 @@ > > > >

The most important participants in the project are people > > who use our software. > > > > -

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 > href="https://mail-archives.apache.org/mod_mbox/couchdb-user/">the > > user mailing list, third-party support forums, blogs, and social > > media. Users who participate in this way automatically become > > contributors. > > +

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 > href="https://lists.apache.org/list.html?user@couchdb.apache.org">the > > user mailing list, third-party support forums, blogs, and social > > media. Users who participate in this way automatically become > > contributors. > > > >

2.2. Contributors

> > > > @@ -152,9 +153,9 @@ > > > >

Our goal is to build a community of trust, reduce mailing list > > traffic, and deal with disagreements swiftly when they occur. > > > > -

All decision making must happen on > href="https://mail-archives.apache.org/mod_mbox/#couchdb">the > > mailing lists. 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. > > +

All decision making must happen on > href="https://couchdb.apache.org/#mailing-lists">the mailing > > lists. 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. > > > > -

Decisions should be made on the mailing list associated with the > > decision. For example, marketing decisions happen on > href="https://mail-archives.apache.org/mod_mbox/couchdb-marketing/">the > > marketing list. 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. > > +

Decisions should be made on the mailing list associated with the > > decision. For example, marketing decisions happen on > href="https://lists.apache.org/list.html?marketing@couchdb.apache.org > ">the > > marketing list. 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. > > > >

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 @@ > > > >

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. > > > > -

Sometimes, you might not be sure what the community would want. > > If this is the case, you can post a note to the appropriate > href="https://mail-archives.apache.org/mod_mbox/#couchdb">mailing > > list 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. > > +

Sometimes, you might not be sure what the community would want. > > If this is the case, you can post a note to the appropriate > href="https://couchdb.apache.org/#mailing-lists">mailing list > > 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. > > > >

An important side effect of this policy is that silence is > > assent. 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 @@ > > > > > > > > -

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 > > decision type. More detail on > href="#approval">approval models, vetos, and > > decision types is available in sections 3.4, > > 3.5., and 3.6 respectively. > > +

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 > > decision type. More detail on > href="#approval">approval models, RTC and > > technical vetos, RFCs, API > > changes and deprecations and decision types > > is available in the following sections. > > > >

All formal voting must be done in an email thread with the > > appropriate subject tag. 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 @@ > > > >

For electing a new Chair, the PMC may opt to use Single > > Transferable Vote (STV) which comes with its own rules. > href="http://steve.apache.org/">Apache STeVe was specifically > > designed to enable this process. > > > > -

3.5. Review-Then-Commit, API Changes and Technical > > Vetos

> > +

3.5. Review-Then-Commit and Technical Vetos

> > > > -

Typically, CouchDB uses the > href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit > ">Review-Then-Commit > > (RTC) 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 > > master, 1.6.x, and so on. Notifications of > > these changes are sent to > href="https://mail-archives.apache.org/mod_mbox/couchdb-commits/">the > > commits mailing list. It is expected that the rest of the > > community is regularly reviewing these changes. > > - > > -

Whenever a change is proposed to a release branch or > > master 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 > > must be announced on the developer mailing list, > > and a minimum of a lazy consensus decision is > > required. 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.

> > +

Typically, CouchDB uses the > href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit > ">Review-Then-Commit > > (RTC) 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 > > master, 1.6.x, and so on. Notifications of > > these changes are sent to > href="https://lists.apache.org/list.html?commits@couchdb.apache.org">the > > commits mailing list, with GitHub discussion appearing on > href=" > https://lists.apache.org/list.html?notifications@couchdb.apache.org">the > > notifications mailing list. It is expected that the rest of the > > community is regularly reviewing these changes. > > > >

Any change made to a release branch or to the > > master branch is a technical decision 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. 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 @@ > > > >

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. > > > > -

3.6. Decision Types

> > +

3.6 Request For Comment (RFC) process

> > + > > +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: > > + > > +
    > > +
  • Start a [DISCUSS] thread on > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the > > developer mailing list. Discuss your proposal in detail, > > including which modules/applications are affected, any HTTP API > > additions and deprecations, and security issues.
    • > > +
  • When there is consensus on the approach from the community, > > complete the RFC > > template and work through any final revisions to the document, > > with the support of the developer mailing list.
    • > > +
  • Start the RFC vote on the developer mailing > > list. Hold the vote according to the lazy majority process: > > at least 3 +1 votes, and more binding +1 than binding -1 votes.
    • > > +
> > + > > +

3.7 API changes and deprecations

> > + > > +

Whenever a change is proposed to a release branch or > > master 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 > > must be announced on > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the > > developer mailing list, and a minimum of a lazy > > consensus decision is required. > > + > > +

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.

> > + > > +

3.8. Decision Types

> > > >

This section describes the various decision types and the > > rules that apply to them.

> > > > @@ -326,12 +343,22 @@ > > > > Technical decision > > A technical decision is any change made to a release > > branch. > > - > href="https://mail-archives.apache.org/mod_mbox/couchdb-commits/ > ">Commits > > list > > + > href="https://lists.apache.org/list.html?commits@couchdb.apache.org > ">Commits > > list > > Allowed for trivial changes > > RTC > > No > > Committers > > - Yes > > + Yes > > + > > + > > + Request For Comments (RFC) decision > > + A decision on a specific proposal to alter CouchDB in a > > significant way. > > + > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main > > development list > > + No > > + Lazy majority > > + No > > + Committers > > + No > > > > > > Non-technical decision > > @@ -354,7 +381,7 @@ > >
> >
> > A veto is only valid when it is justified with a sound technical > > argument. > > - > href="https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main > > development list > > + > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main > > development list > > No > > Lazy 2/3 majority > > No > > @@ -368,7 +395,7 @@ > >
> >
> > Release candidates can be prepared by anyone. > > - > href="https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main > > development list > > + > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main > > development list > > No > > Lazy majority > > No > > @@ -446,7 +473,7 @@ > > > > Create or amend official document > > Create or amend any document marked as official. > > - > href="https://mail-archives.apache.org/mod_mbox/couchdb-dev/">Main > > development list > > + > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main > > development list > > No > > Lazy 2/3 majority > > No > > > --000000000000a7605a05836992ec--