I'm also not super keen on the "not directly affiliated with the proposer's employer”. 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 <woh...@apache.org> 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" <rnew...@apache.org> > > To: "Joan Touzet" <woh...@apache.org> > > Cc: "CouchDB Developers" <dev@couchdb.apache.org>, "CouchDB PMC" < > priv...@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” 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’t see how this piece is coupled with RFC, especially when > > writing RFC’s, 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 “RFC before code” 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 <woh...@apache.org> 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" <rnew...@apache.org> > > >> To: "CouchDB PMC" <priv...@couchdb.apache.org> > > >> Cc: "Joan Touzet" <woh...@apache.org>, "CouchDB Developers" > > >> <dev@couchdb.apache.org> > > >> Sent: Thursday, February 14, 2019 4:26:31 PM > > >> Subject: Re: [DISCUSS] Proposed Bylaws changes > > >> > > >> I am +1 on the RFC’s and -1 on the "not directly affiliated with > > >> the > > >> proposer's employer” item. > > >> > > >> B. > > >> > > >>> On 13 Feb 2019, at 11:13, Jan Lehnardt <j...@apache.org> wrote: > > >>> > > >>> Sounds fantastic, thanks too for the additional context! I’d love > > >>> for us to lead the way here (yet again). > > >>> > > >>> Best > > >>> Jan > > >>> — > > >>> > > >>>> On 12. Feb 2019, at 20:15, Joan Touzet <woh...@apache.org> > > >>>> 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/8ae3a5a230b1717d7affe23625eeb288635aa542 > > >>>> > > >>>> 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’s 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 (“We have more!” “Ours were first!”) 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’t > > >>>>>> 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 “the source” 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/ > > >>> > > >> > > >> > > > > >
