From dev-return-48263-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Fri Feb 8 17:55:57 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 A8A7118060E for ; Fri, 8 Feb 2019 18:55:56 +0100 (CET) Received: (qmail 25154 invoked by uid 500); 8 Feb 2019 17:55:55 -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 25143 invoked by uid 99); 8 Feb 2019 17:55:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Feb 2019 17:55:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 982F3C254F for ; Fri, 8 Feb 2019 17:55:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id On-1Qp7R4W81 for ; Fri, 8 Feb 2019 17:55:51 +0000 (UTC) Received: from smtp.justsomehost.net (smtp.justsomehost.net [204.11.51.157]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 3CB775FC91 for ; Fri, 8 Feb 2019 17:55:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.justsomehost.net (Postfix) with ESMTP id C14165800AB for ; Fri, 8 Feb 2019 12:55:48 -0500 (EST) Received: from smtp.justsomehost.net ([127.0.0.1]) by localhost (smtp.justsomehost.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8Ko1cUbs9j5Y for ; Fri, 8 Feb 2019 12:55:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.justsomehost.net (Postfix) with ESMTP id BC58F580186 for ; Fri, 8 Feb 2019 12:55:47 -0500 (EST) X-Virus-Scanned: amavisd-new at smtp.justsomehost.net Received: from smtp.justsomehost.net ([127.0.0.1]) by localhost (smtp.justsomehost.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xOzv_xguvL1L for ; Fri, 8 Feb 2019 12:55:47 -0500 (EST) Received: from smtp.justsomehost.net (smtp.justsomehost.net [204.11.51.157]) by smtp.justsomehost.net (Postfix) with ESMTP id A6E325800AB for ; Fri, 8 Feb 2019 12:55:47 -0500 (EST) Date: Fri, 8 Feb 2019 12:55:47 -0500 (EST) From: Joan Touzet Reply-To: wohali@apache.org To: CouchDB Developers Message-ID: <650465542.2939.1549648551124.JavaMail.Joan@BRAIN> In-Reply-To: <277561DB-B23C-4EAA-84DB-41C9D1657056@apache.org> References: <1483869506.2384.1549391249197.JavaMail.Joan@BRAIN> <277561DB-B23C-4EAA-84DB-41C9D1657056@apache.org> Subject: Re: [DISCUSSION] Proposed new RFC process MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [204.11.51.157] X-Mailer: Zimbra 8.8.9_GA_3026 (Zimbra Desktop/7.3.1_13063_Windows) Thread-Topic: Proposed new RFC process Thread-Index: jMPgqi3iZvkK40vAUcpfNWX1soeg7w== Adam asked one question on our dev IRC that I wanted to be sure made it into this thread: "It's not totally clear to me - is the RFC supposed to encourage a discussion about _what_ gets built, or _how_ it gets built?" Jan responded: "It is meant to let the project get in on early design phases of features that would otherwise have developed elsewhere and would only see the ASF side as a fully fledged, or partly fledged PR. "Maybe this way: an rfc is the vehicle by which we arrive at the what and how of (major) changes/features making it into CouchDB." I agree, and would add that it's intended to cap off a [DISCUSS] thread with the actual change proposal, before serious development starts. Prototyping would be expected before an RFC, because how else do you know if it's what you're going to do? Finally, the RFC then forms the basis of the documentation update later. If there are no objections, I'll roll this into next week's post on bylaws changes. I'd like to get this VOTEd on (just to ensure there is broad support, since the thread was relatively quiet) and our bylaws updated to match. Did anyone want to take a run at writing a GH Issue monitoring bot? -Joan ----- Original Message ----- > From: "Jan Lehnardt" > To: "CouchDB Developers" , "Joan Touzet" > Sent: Thursday, February 7, 2019 5:33:00 AM > Subject: Re: [DISCUSSION] Proposed new RFC process >=20 > I=E2=80=99m favour of all that=E2=80=99s outlined here. Thanks for gettin= g this > written up, Joan! >=20 > Best > Jan > =E2=80=94 >=20 > > On 5. Feb 2019, at 19:27, Joan Touzet wrote: > >=20 > > Hi everyone, > >=20 > > One thing that has plagued the CouchDB project for a while is the > > introduction of new features without much discussion prior to the > > feature landing. > >=20 > > To put all the cards on the table: it is good that IBM/Cloudant > > have > > been benevolent and have contributed significant new functionality > > with > > every recent release of CouchDB. Some highlights include: > >=20 > > 2.0: clustering code (n=C3=A9e bigcouch) > > 2.1: replication scheduler > > 2.2: pluggable storage engines > > 2.3: clustered purge > >=20 > > However, most of these features landed as PRs on the CouchDB > > repository > > already complete, or at the very least, with the design process > > already > > finished, with only implementation details remaining. In at least a > > couple of the cases, the PRs were so large that any review by > > non-Cloudant people was effectively impossible. And, of course, by > > the > > time the PR lands, any prototype implementations that would have > > informed the final PR (and helped understand how it works) are not > > visible or available. Further, documentation is often lacking at > > this > > stage, though increasingly I see excellent README.md files placed > > at the > > top of each OTP application that are especially welcome. > >=20 > > This needs to change. > >=20 > > Fortunately, the Internet has a good precedent for dealing with > > this > > very issue: the RFC[1]. While we don't need the entire pomp and > > circumstance workflow that follows the RFC, we can certainly steal > > that > > nice template. > >=20 > > I've taken a pass at adapting the RFC template to GitHub's and > > CouchDB's needs (PRs welcome): > >=20 > > https://raw.githubusercontent.com/apache/couchdb/master/.github/ISSU= E_TEMPLATE/rfc.md > > https://github.com/apache/couchdb/issues/new?labels=3Drfc%2C+discuss= ion&template=3Drfc.md > >=20 > > I believe this template is not onerous to fill out, and if it > > contained > > sufficient detail on the proposal, would give committers enough > > knowledge > > to be able to make informed decisions about the proposal - i.e., > > vote on > > it. > >=20 > >=20 > > I propose the PMC REQUIRE this template for any substantial change > > to > > CouchDB's HTTP API, or its behaviour. > >=20 > > I propose developers SHOULD use this template for any change to > > CouchDB's HTTP API or behaviour, even small ones. > >=20 > > I propose developers COULD use this template for any minor change > > to > > CouchDB, but it's unnecessary if it's something like a debug > > interface, > > a config file improvement, etc. Documentation and Fauxton changes > > would > > likely be exempt from this workflow, too. > >=20 > >=20 > > I imagine the workflow being like this: > >=20 > > * [DISCUSS]ions like the ones happening now for FDB happen on the > > list. > >=20 > > * Consensus starts to be reached, or, at the very least, the > > important > > advantages and disadvantages of the proposal have been > > clarified. > >=20 > > * A filled-in RFC is filed in GH Issues. > >=20 > > * (Optional.) A bot watches for issues of this type and forwards > > notice > > of them to dev@. This becomes a [PROPOSAL] per our bylaws at > > that > > point. > >=20 > > * Committers formally vote +1/+0.5/0/-0.5/-1 on the proposal in > > GH. > >=20 > > * (Optional.) A bot could close the vote and sum the responses > > from > > committers, emailing the results to dev@. > >=20 > > * Repeat if necessary (because the RFC gets rewritten/improved, > > etc.) > >=20 > > Note the only two new steps are 1) ensuring that we actually HAVE > > the > > discussion on the mailing list about the proposed change; and 2) a > > new > > template we should use for these major changes, which itself should > > help > > make understanding the proposal and the voting process smoother. > >=20 > > For me, the question that remains is: at what point do we REQUIRE > > the > > proposed RFC process to be followed? When is a change > > "substantial?" And > > I think that it may be sufficient at this point to leave it > > grey-area, > > with the PMC weighing in as a group if necessary. (The easiest > > thing to > > do is to simply say "do the RFC anyway," because if any proposal is > > sufficiently unclear as to not be easily translatable into an RFC, > > then > > it is probably too weak of a proposal to stand muster without one.) > >=20 > > One other question is whether or not we add a new decision type to > > our > > decision matrix in the Bylaws for this. Our rules are somewhat > > unclear > > here, since this is both a technical and a non-technical decision, > > meaning it probably defaults over to our non-technical decision > > type. > > That type is lazy majority, with committers being given binding > > votes, > > but importantly does NOT allow for vetoes (blocking -1 votes). (I > > have > > one other topic for the Bylaws mailing, which will be separate, so > > we > > can pick up this discusison in that thread if desired.) > >=20 > > Thoughts? > >=20 > > -Joan "evolve or perish!" Touzet > >=20 > > [1]: https://www.ietf.org/standards/rfcs/ >=20 > -- > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ >=20 >=20