A counter point would be* that this would be a forcing function for the folks who do the work here to use some of their time for community building so that that delay won’t ever happen.
* I’m not saying I’m making this argument, but it might be a useful point to consider. * * * I also don’t think this proposal is based on a priori bad faith, but as a safety net for habits that are easy to fall into. Best Jan — > On 15. Feb 2019, at 08:56, Garren Smith <gar...@apache.org> wrote: > > 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/ >>>>>> >>>>> >>>>> >>> >>> >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
