From dev-return-48302-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Sun Feb 17 18:51:35 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 04B08180657 for ; Sun, 17 Feb 2019 19:51:34 +0100 (CET) Received: (qmail 25440 invoked by uid 500); 17 Feb 2019 18:51:34 -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 25419 invoked by uid 99); 17 Feb 2019 18:51:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Feb 2019 18:51:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E0DB6C7DF1; Sun, 17 Feb 2019 18:51:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.999 X-Spam-Level: * X-Spam-Status: No, score=1.999 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id rhoX_XP35pFl; Sun, 17 Feb 2019 18:51:29 +0000 (UTC) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-oln040092065041.outbound.protection.outlook.com [40.92.65.41]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 5800560E12; Sun, 17 Feb 2019 18:51:28 +0000 (UTC) Received: from DB5EUR01FT010.eop-EUR01.prod.protection.outlook.com (10.152.4.53) by DB5EUR01HT222.eop-EUR01.prod.protection.outlook.com (10.152.5.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10; Sun, 17 Feb 2019 18:51:20 +0000 Received: from VI1PR0502MB4093.eurprd05.prod.outlook.com (10.152.4.55) by DB5EUR01FT010.mail.protection.outlook.com (10.152.4.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Sun, 17 Feb 2019 18:51:20 +0000 Received: from VI1PR0502MB4093.eurprd05.prod.outlook.com ([fe80::6d60:3562:625e:f3fa]) by VI1PR0502MB4093.eurprd05.prod.outlook.com ([fe80::6d60:3562:625e:f3fa%5]) with mapi id 15.20.1622.018; Sun, 17 Feb 2019 18:51:20 +0000 From: Reddy B. To: "private@couchdb.apache.org" , "dev@couchdb.apache.org" , "wohali@apache.org" Subject: RE: [DISCUSS] Proposed Bylaws changes Thread-Topic: [DISCUSS] Proposed Bylaws changes Thread-Index: 4MW6fRV2zxOn9+O2y/l+/aoRZWPWZ54SIEIAAEevWIAAAC7KgAAAhJ+AAAIr9gAAEx0+AAAWwxqAAABUMQAAABrSAABjb5eT Date: Sun, 17 Feb 2019 18:51:20 +0000 Message-ID: References: <226129378.171.1549998945720.JavaMail.Joan@BRAIN> <638BA666-444C-4894-8551-9DF13B1C5A4C@apache.org> <586995337.515.1550179906970.JavaMail.Joan@BRAIN> <44BE4854-2E3C-48A4-9A6D-1B872B84F13B@apache.org> <425047905.533.1550184527217.JavaMail.Joan@BRAIN> <1271094210.638.1550256473083.JavaMail.Joan@BRAIN> <1550257034.3392042.1658772600.603C4CDB@webmail.messagingengine.com>,<616758329.721.1550257215879.JavaMail.Joan@BRAIN> In-Reply-To: <616758329.721.1550257215879.JavaMail.Joan@BRAIN> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:6E2BDF13A7D17353DA72AC464D7B71260DA116AC9F28E3561077737D43561F0F;UpperCasedChecksum:34C665A38CDE01F17738D1B0CE849F70D13505E3BF6C9A9E8E4B4A9BE332F64C;SizeAsReceived:7528;Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [AWWtq4BLVgQtH6UgdvzRUfz1uzKTvd6hoEBXmkz9yz2wnMhQQ9fywwrdfbYjBy60] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045);SRVR:DB5EUR01HT222; x-ms-traffictypediagnostic: DB5EUR01HT222: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(4566010)(82015058);SRVR:DB5EUR01HT222;BCL:0;PCL:0;RULEID:;SRVR:DB5EUR01HT222; x-microsoft-antispam-message-info: a72DD6WqX+8H+uB1w8Pfra+y0quSfPOc9cx4BR4cc/JTwWbmNDONdzjDmi+SA2Dx Content-Type: multipart/alternative; boundary="_000_VI1PR0502MB4093F708344C9D9B9404B037F4620VI1PR0502MB4093_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 9bd8b953-1c55-4da7-b616-8bcad099ae8b X-MS-Exchange-CrossTenant-Network-Message-Id: edfe0ddb-8fe9-44c0-a2f5-08d69508e835 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 9bd8b953-1c55-4da7-b616-8bcad099ae8b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2019 18:51:20.6249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT222 --_000_VI1PR0502MB4093F708344C9D9B9404B037F4620VI1PR0502MB4093_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As a user I would tend to find this safeguard reassuring. For example, when developments such as the FDB branch are happening, this w= ould provide the community additional peace of mind. I too think that the problem addressed by this proposal doesn't exist (yet?= ) in this project. I am very impressed and admirative of the quality of th= is community. But considering what's happening in the wild and the manoeuve= ring of certain companies, it's difficult not to feel naive by always assum= ing good faith. I also do not think that this bylaw would assume bad faith, the way I see i= t, it would put everyone in a better position to assume good faith. This is= similar to discussing with your spouse giving each other a GPS tracker (an= app or something) so that one spouse can now where the other is at all tim= es. Is it about building trust, or is it about distrust. This is the situat= ion we are in. I think that once the issue is brought up by one the spouses, it becomes so= mething you need to deal with as early as possible to save the marriage, ot= herwise worries will turn into distrust, which will turn into perceptions a= nd from that point, hell is the only limit left. My view is that a solution= in the form of a rule applying to both spouses equally is a good compromis= e that is building trust rather than assuming distrust. Forgive the analogy. ________________________________ De : Joan Touzet Envoy=E9 : vendredi 15 f=E9vrier 2019 20:00:14 =C0 : private@couchdb.apache.org Cc : dev@couchdb.apache.org Objet : Re: [DISCUSS] Proposed Bylaws changes And yet we have evidence from other ASF projects that this is not always the case. All I am trying to do is have a backstop against that from happening here. But if no one wants it, then fine, I give up. -Joan ----- Original Message ----- > From: "Robert Newson" > To: dev@couchdb.apache.org > Cc: "private@couchdb.apache.org Private" > Sent: Friday, February 15, 2019 1:57:14 PM > Subject: Re: [DISCUSS] Proposed Bylaws changes > > https://apache.org/foundation/how-it-works.html#hats > > INDIVIDUALS COMPOSE THE ASF > All of the ASF including the board, the other officers, the > committers, and the members, are participating as individuals. That > is one strength of the ASF, affiliations do not cloud the personal > contributions. > > Unless they specifically state otherwise, whatever they post on any > mailing list is done as themselves. It is the individual > point-of-view, wearing their personal hat and not as a mouthpiece > for whatever company happens to be signing their paychecks right > now, and not even as a director of the ASF. > > All of those ASF people implicitly have multiple hats, especially the > Board, the other officers, and the PMC chairs. They sometimes need > to talk about a matter of policy, so to avoid appearing to be > expressing a personal opinion, they will state that they are talking > in their special capacity. However, most of the time this is not > necessary, personal opinions work well. > > Some people declare their hats by using a special footer to their > email, others enclose their statements in special quotation marks, > others use their apache.org email address when otherwise they would > use their personal one. This latter method is not reliable, as many > people use their apache.org address all of the time. > > -- > Robert Samuel Newson > rnewson@apache.org > > On Fri, 15 Feb 2019, at 18:47, Joan Touzet wrote: > > Garren, > > > > RFCs are intended for major changes to our projects, not for minor > > improvments. > > > > Do you foresee massive changes to nano and fauxton? > > > > Do you not see that a single employer driving ~all the development > > of either or both of these as a significant concern re: the health > > of our community? > > > > -Joan > > > > ----- Original Message ----- > > > From: "Garren Smith" > > > To: "private@couchdb.apache.org Private" > > > , "Joan Touzet" > > > Cc: "CouchDB Developers" > > > Sent: Friday, February 15, 2019 2:56:04 AM > > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > > > I'm also not super keen on the "not directly affiliated with the > > > proposer's > > > employer=94. I think this will put unnecessary strain on the > > > community. > > > Take > > > the Fauxton and Nano.js project. The majority of work on those > > > projects > > > come from IBM affiliated developers. We do have a smaller group > > > of > > > community developers. That small group of community developers > > > would > > > have > > > to review all RFC's and approve them and ideally not hold up > > > development on > > > a feature for a few weeks while they try and find time to get to > > > it. > > > > > > On Fri, Feb 15, 2019 at 12:49 AM Joan Touzet > > > wrote: > > > > > > > Hi, > > > > > > > > Thanks. I'll make another attempt to sway others, and I'd like > > > > to > > > > hear > > > > from more people on this thread. > > > > > > > > I don't see the harm in this, it would rarely if ever be > > > > invoked, > > > > and > > > > it allows us to point to a concrete, solid action we have taken > > > > to > > > > ensure we don't have a runaway project in the future. I would > > > > think > > > > it could be a guiding light for other ASF projects that have > > > > lost > > > > their > > > > way (where we, I continue to assert, have not). > > > > > > > > Remember that votes on RFCs are the *committer* community, not > > > > the > > > > PMC. > > > > I'd be shocked if the PMC remained entirely silent on a > > > > proposal, > > > > but > > > > it indeed could be possible that committers could get an RFC > > > > together > > > > "while the PMC isn't looking" (say, over a holiday). Granted > > > > it'd > > > > be in > > > > bad form, and the PMC could still take steps to correct things > > > > after > > > > the action, but it'd be annoying to deal with. > > > > > > > > Again all I am trying to do here is put in a limiter in case > > > > the > > > > PMC > > > > and committer base /were/ to get stacked against the community. > > > > If > > > > that > > > > were to occur, your argument that the PMC could step in at that > > > > point > > > > is moot, because the PMC would already be stacked in that > > > > direction. > > > > This would protect the community from the negative effects of > > > > that > > > > happening. > > > > > > > > -Joan > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Robert Samuel Newson" > > > > > To: "Joan Touzet" > > > > > Cc: "CouchDB Developers" , "CouchDB > > > > > PMC" > > > > > < > > > > private@couchdb.apache.org> > > > > > Sent: Thursday, February 14, 2019 4:46:35 PM > > > > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > > > > > > > Hi, > > > > > > > > > > Sure. > > > > > > > > > > Any member of the PMC who is railroading changes through on > > > > > behalf of > > > > > their employer to the detriment of this project should be > > > > > disciplined, ultimately losing their PMC membership (and > > > > > their > > > > > binding vote on future changes). > > > > > > > > > > The "not directly affiliated with proposer's employer=94 seems > > > > > to > > > > > presume bad faith on the part of some of those with binding > > > > > votes > > > > > at > > > > > worst, and, at best, is stating that the PMC already > > > > > distrusts > > > > > its > > > > > members that happen to be employed by IBM. If that is > > > > > currently > > > > > the > > > > > case, the PMC should act directly and censure those members > > > > > who > > > > > have > > > > > acted contrary to the requirements of an ASF PMC member. > > > > > > > > > > I don=92t see how this piece is coupled with RFC, especially > > > > > when > > > > > writing RFC=92s, and taking them through a community review > > > > > process, > > > > > is likely to mitigate the issue of significant work being > > > > > designed > > > > > in private but ultimately contributed to CouchDB publicly. > > > > > > > > > > If the =93RFC before code=94 approach does not work out, I will > > > > > add > > > > > my > > > > > support to the affiliation requirement, but with a heavy > > > > > heart. > > > > > To > > > > > presume such bad faith within the PMC, or to suspect it so > > > > > strongly > > > > > as to embed pre-emptive measures into our bylaws, points at > > > > > issues > > > > > deeper than a bylaw change can reasonably address. Other, > > > > > stronger > > > > > responses would seem more appropriate should that come to > > > > > pass. > > > > > > > > > > B. > > > > > > > > > > > On 14 Feb 2019, at 21:31, Joan Touzet > > > > > > wrote: > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > Care to give any more detail on your -1? > > > > > > > > > > > > I gave a fairly extensive argument as to why I think such a > > > > > > safeguard is important for our community. I also feel it > > > > > > would > > > > > > be meaningless to push through an RFC without community > > > > > > support. > > > > > > But our current bylaws would make this very > > > > > > straightforward. > > > > > > Why not put in this "backstop?" > > > > > > > > > > > > -Joan > > > > > > > > > > > > ----- Original Message ----- > > > > > >> From: "Robert Samuel Newson" > > > > > >> To: "CouchDB PMC" > > > > > >> Cc: "Joan Touzet" , "CouchDB > > > > > >> Developers" > > > > > >> > > > > > >> Sent: Thursday, February 14, 2019 4:26:31 PM > > > > > >> Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > > >> > > > > > >> I am +1 on the RFC=92s and -1 on the "not directly > > > > > >> affiliated > > > > > >> with > > > > > >> the > > > > > >> proposer's employer=94 item. > > > > > >> > > > > > >> B. > > > > > >> > > > > > >>> On 13 Feb 2019, at 11:13, Jan Lehnardt > > > > > >>> wrote: > > > > > >>> > > > > > >>> Sounds fantastic, thanks too for the additional context! > > > > > >>> I=92d > > > > > >>> love > > > > > >>> for us to lead the way here (yet again). > > > > > >>> > > > > > >>> Best > > > > > >>> Jan > > > > > >>> =97 > > > > > >>> > > > > > >>>> On 12. Feb 2019, at 20:15, Joan Touzet > > > > > >>>> > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>> Hi everyone, > > > > > >>>> > > > > > >>>> There appears to be general consensus on the RFC > > > > > >>>> process, > > > > > >>>> with > > > > > >>>> no > > > > > >>>> objections to the proposal itself. > > > > > >>>> > > > > > >>>> I'd like to propose the following changes to our bylaws: > > > > > >>>> > > > > > >>>> > > > > https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe2= 3625eeb288635aa542 > > > > > >>>> > > > > > >>>> Quick summary: > > > > > >>>> > > > > > >>>> * Added the RFC proposal process > > > > > >>>> * The RFC will become an official template as part of > > > > > >>>> this > > > > > >>>> * https://github.com/apache/couchdb/pull/1914 adds > > > > > >>>> Bob's > > > > > >>>> request > > > > > >>>> to include a Security section > > > > > >>>> > > > > > >>>> * Proposed a new "qualified lazy majority" approval > > > > > >>>> model > > > > > >>>> for > > > > > >>>> RFCs: > > > > > >>>> * Requires 3 binding +1 votes > > > > > >>>> * Requires more binding +1 votes than binding -1 votes > > > > > >>>> * (NEW) Requires at least +1 binding vote from an > > > > > >>>> individual > > > > > >>>> not directly affiliated with the proposer's employer > > > > > >>>> (if > > > > > >>>> applicable) > > > > > >>>> > > > > > >>>> * Changed URLs to use the new Pony Mail web interface > > > > > >>>> (yay!) > > > > > >>>> > > > > > >>>> While today we are in a great situation where no single > > > > > >>>> entity > > > > > >>>> dominates > > > > > >>>> CouchDB development (to the exclusion of others), I > > > > > >>>> believe > > > > > >>>> this > > > > > >>>> new > > > > > >>>> approval model (just for RFCs) will prevent that from > > > > > >>>> occurring > > > > > >>>> in > > > > > >>>> the > > > > > >>>> future, and will ease a long-standing concern I have > > > > > >>>> held. > > > > > >>>> > > > > > >>>> > > > > > >>>> If there is no strong objection, I will start the VOTE > > > > > >>>> later > > > > > >>>> this > > > > > >>>> week. > > > > > >>>> As this is both creating and amending our official > > > > > >>>> documents, > > > > > >>>> the > > > > > >>>> vote > > > > > >>>> will be a lazy 2/3 majority vote, with binding votes > > > > > >>>> only > > > > > >>>> from > > > > > >>>> PMC > > > > > >>>> members. > > > > > >>>> > > > > > >>>> > > > > > >>>> Why is this so important to me? Recently, on another ASF > > > > > >>>> mailing > > > > > >>>> list, > > > > > >>>> there was a discussion about some of the changes > > > > > >>>> happening > > > > > >>>> in > > > > > >>>> the > > > > > >>>> commercial world, and as it relates to big companies > > > > > >>>> giving > > > > > >>>> back > > > > > >>>> to open > > > > > >>>> source. (You may have read about some competing database > > > > > >>>> projects > > > > > >>>> changing their license, for instance.) > > > > > >>>> > > > > > >>>> Allen Wittenauer graciously allowed me to excerpt his > > > > > >>>> post, > > > > > >>>> which > > > > > >>>> is > > > > > >>>> critical of the Apache Hadoop community, and share it > > > > > >>>> here > > > > > >>>> as a > > > > > >>>> cautionary tale: > > > > > >>>> > > > > > >>>>>> This pretty much ignores the committer hoarding > > > > > >>>>>> that > > > > > >>>>>> is > > > > > >>>>>> happening in a lot of ASF projects. It=92s > > > > > >>>>>> something > > > > > >>>>>> that > > > > > >>>>>> Jeff > > > > > >>>>>> hinted at in a previous reply that I think people > > > > > >>>>>> completely > > > > > >>>>>> missed: > > > > > >>>>>> > > > > > >>>>>>> The obvious reality is that the companies who build > > > > > >>>>>>> service > > > > > >>>>>>> around > > > > > >>>>>>> "pay to call me when it breaks" are very, very often > > > > > >>>>>>> the > > > > > >>>>>>> same > > > > > >>>>>>> companies who hire all the committers, who fund all > > > > > >>>>>>> the > > > > > >>>>>>> dev, > > > > > >>>>>>> who end > > > > > >>>>>>> up in danger when a cloud provider offers their > > > > > >>>>>>> product > > > > > >>>>>>> as a > > > > > >>>>>>> service. > > > > > >>>>>> > > > > > >>>>>> Most of the Hadoop vendors tried to hire as many > > > > > >>>>>> of > > > > > >>>>>> the > > > > > >>>>>> committers as they possibly could and was even > > > > > >>>>>> part > > > > > >>>>>> of > > > > > >>>>>> some > > > > > >>>>>> PR campaigns (=93We have more!=94 =93Ours were > > > > > >>>>>> first!=94) > > > > > >>>>>> This > > > > > >>>>>> resulted in the community outside of those > > > > > >>>>>> vendors > > > > > >>>>>> being > > > > > >>>>>> mostly ignored. This also built a feedback loop > > > > > >>>>>> where > > > > > >>>>>> PMC > > > > > >>>>>> members promote their coworkers at a > > > > > >>>>>> significantly > > > > > >>>>>> higher > > > > > >>>>>> rate than non-coworkers because the only > > > > > >>>>>> contributions > > > > > >>>>>> that > > > > > >>>>>> were being looked at were the ones that helped > > > > > >>>>>> their > > > > > >>>>>> employers. (Anecdotally, coworkers: committer in > > > > > >>>>>> 6 > > > > > >>>>>> months, > > > > > >>>>>> non-coworkers, ~1-2 years, if ever) As a result, > > > > > >>>>>> the > > > > > >>>>>> project > > > > > >>>>>> is a shell of its former self since it was > > > > > >>>>>> impossible > > > > > >>>>>> for > > > > > >>>>>> outsiders to make major, disruptive advancements > > > > > >>>>>> in > > > > > >>>>>> the > > > > > >>>>>> project. Worse yet, Hadoop is now overwhelmingly > > > > > >>>>>> controlled > > > > > >>>>>> by one company since two of those vendors were > > > > > >>>>>> forced > > > > > >>>>>> to > > > > > >>>>>> merge. > > > > > >>>>> [snip] > > > > > >>>>>> This is probably the key reason why a lot of > > > > > >>>>>> companies > > > > > >>>>>> participate in open source. Maybe if companies > > > > > >>>>>> didn=92t > > > > > >>>>>> feel > > > > > >>>>>> the need to hire every single person they could > > > > > >>>>>> get > > > > > >>>>>> their > > > > > >>>>>> hands on to try and control the project, maybe > > > > > >>>>>> the > > > > > >>>>>> cloud > > > > > >>>>>> providers would be more willing to donate man > > > > > >>>>>> power. > > > > > >>>>>> As > > > > > >>>>>> it > > > > > >>>>>> is, there is little point for anyone outside of a > > > > > >>>>>> company > > > > > >>>>>> whose mission is to be =93the source=94 for their > > > > > >>>>>> project > > > > > >>>>>> (officially or unofficially) to contribute to > > > > > >>>>>> non-diverse > > > > > >>>>>> projects. > > > > > >>>> > > > > > >>>> From my informal chats with people at ApacheCon 2018 in > > > > > >>>> Montreal, > > > > > >>>> this > > > > > >>>> is a hot-button topic. I'd like to get CouchDB out from > > > > > >>>> under > > > > > >>>> this > > > > > >>>> cloud. > > > > > >>>> > > > > > >>>> Again I am NOT ASSERTING that this is where we are > > > > > >>>> today. I > > > > > >>>> think > > > > > >>>> our > > > > > >>>> dev community works well together and is not controlled > > > > > >>>> by a > > > > > >>>> single > > > > > >>>> entity. I just want to remove the possibility for this > > > > > >>>> sort > > > > > >>>> of > > > > > >>>> abuse to > > > > > >>>> occur, and I think that doing so thru the RFC process is > > > > > >>>> the > > > > > >>>> right > > > > > >>>> step > > > > > >>>> at this time. > > > > > >>>> > > > > > >>>> It is in everyone's best interest that RFCs happen, that > > > > > >>>> we > > > > > >>>> have > > > > > >>>> consensus agreement on them, and that an open vote > > > > > >>>> happens > > > > > >>>> where > > > > > >>>> it's > > > > > >>>> clear that no single party is forcing through changes > > > > > >>>> against > > > > > >>>> the > > > > > >>>> will > > > > > >>>> of other committed parties. > > > > > >>>> > > > > > >>>> -Joan > > > > > >>> > > > > > >>> -- > > > > > >>> Professional Support for Apache CouchDB: > > > > > >>> https://neighbourhood.ie/couchdb-support/ > > > > > >>> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > --_000_VI1PR0502MB4093F708344C9D9B9404B037F4620VI1PR0502MB4093_--