Re: [DISCUSS] Proposed Bylaws changes

[Joan Touzet <wo...@apache.org>]

Since there isn't clear consensus on part of this, I'm going to start 2 VOTE threads for changing the bylaws, one for the RFC process which has broad-spectrum support, and one for the +1 rule change. 

-Joan 

----- Original Message -----

> From: "Reddy B." <re...@live.fr>
> To: private@couchdb.apache.org, dev@couchdb.apache.org,
> wohali@apache.org
> Sent: Sunday, February 17, 2019 1:51:20 PM
> Subject: RE: [DISCUSS] Proposed Bylaws changes

> As a user I would tend to find this safeguard reassuring.

> For example, when developments such as the FDB branch are happening,
> this would 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 this community. But considering what's happening in the
> wild and the manoeuvering of certain companies, it's difficult not
> to feel naive by always assuming good faith.

> I also do not think that this bylaw would assume bad faith, the way I
> see it, 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 times. Is it about building trust, or is
> it about distrust. This is the situation we are in.

> I think that once the issue is brought up by one the spouses, it
> becomes something you need to deal with as early as possible to save
> the marriage, otherwise worries will turn into distrust, which will
> turn into perceptions and 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 compromise that is building trust
> rather than assuming distrust.

> Forgive the analogy.

> De : Joan Touzet <wo...@apache.org>
> Envoyé : vendredi 15 février 2019 20:00:14
> À : 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" <rn...@apache.org>
> > To: dev@couchdb.apache.org
> > Cc: "private@couchdb.apache.org Private"
> > <pr...@couchdb.apache.org>
> > 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" <ga...@apache.org>
> > > > To: "private@couchdb.apache.org Private"
> > > > <pr...@couchdb.apache.org>, "Joan Touzet" <wo...@apache.org>
> > > > Cc: "CouchDB Developers" <de...@couchdb.apache.org>
> > > > 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”. 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
> > > > <wo...@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" <rn...@apache.org>
> > > > > > To: "Joan Touzet" <wo...@apache.org>
> > > > > > Cc: "CouchDB Developers" <de...@couchdb.apache.org>, "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”
> > > > > > 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 <wo...@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" <rn...@apache.org>
> > > > > > >> To: "CouchDB PMC" <pr...@couchdb.apache.org>
> > > > > > >> Cc: "Joan Touzet" <wo...@apache.org>, "CouchDB
> > > > > > >> Developers"
> > > > > > >> <de...@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 <ja...@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
> > > > > > >>>> <wo...@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/
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> >