I'll first preface this the fact that I'm totally on board with adding an RFC process for designing large features. I think that's definitely entirely reasonable and is something that could do with some better formalization so that we're all aware of larger developments going on (assuming we'll have a nice tidy place for storing and referring to our RFCs and so on).
> This needs to change. Going through your list: * Merging BigCouch was admittedly big but that work was very public [9], starting in March 2013. The merge/commit was voted on in May 2013 [10] however we didn't actually have a 2.0 release including that code until September 2016 [11]. * Pluggable storage engines were first described at [1] in June 2016. The API was developed in the open. The first commit notification mentioning it was in Feb 2017 [2]. And the PR wasn't merged until Feb 2018 [3]. * The scheduling replicator was first mentioned in March 2016 [4]. The first commit emails started around June 2016 [5]. And it wasn't merged until May 2017 [6]. * The ticket for clustered purge work was opened in March of 2017 [7] with commit notifications starting the same day. That PR wasn't merged until August 2018 [8]. > In at least a couple of the cases, the PRs were so large that > any review by non-Cloudant people was effectively impossible. * BigCouch was a 3 year slog * PSE: PR open for 10 months * Replicator: PR open for 1.5 months * CP: PR open for 1.5 months Yes these were big PRs, and yes they took a long time to review. But there was plenty of time for anyone to do that review (and there were a number of non Cloudant people involved in these listed). > 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. While I'm not sure about prototyping, I do think RFCs would help solve this problem. It definitely helps to know what the reason a PR even exists and maybe why various other approaches were discarded before starting to review it. I don't personally know of much prototyping related to these sorts of features. There's definitely evolution to them based on various restrictions and that is captured on our commits@ lists (obviously in a difficult to consume format post facto, but useful for anyone following along at least). However, I think describing these as "features [that] landed as PRs on the CouchDB repository already complete" is way beyond approximately consistent with history which is what I'm mostly pointing out. Adding RFCs won't solve the issue that large features almost by definition have correspondingly large PRs that can be daunting to review. I do think having an RFC may make it easier, but I don't think its solving the problem as posed. [1] https://lists.apache.org/thread.html/2d4b4623184504502c29da54eede581c1cf91f4de3f94c024bea1e7b@%3Cdev.couchdb.apache.org%3E [2] https://lists.apache.org/thread.html/d83e8ee320d2b7374ee486234bb645d063238b891f7c1d28878636de@%3Ccommits.couchdb.apache.org%3E [3] https://github.com/apache/couchdb/pull/496#event-1497125544 [4] https://lists.apache.org/thread.html/62254e60737450057509adbb43858a1067466a4f957fcbe4e7fd0936@1458412573@%3Cdev.couchdb.apache.org%3E [5] https://lists.apache.org/thread.html/1387b37835bcfb570a094e5aca488138e9544744a6de9fd89e697199@%3Ccommits.couchdb.apache.org%3E [6] https://github.com/apache/couchdb/pull/470#event-1082902923 [7] https://issues.apache.org/jira/browse/COUCHDB-3326 [8] https://github.com/apache/couchdb/pull/1370#event-1800759934 [9] https://twitter.com/davisp/status/312099513613549568 [10] https://lists.apache.org/thread.html/89777918304b3c5c070d45eb55a369a3be37d271047707d8176d17fd@1367958848@%3Cdev.couchdb.apache.org%3E [11] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces99
