couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: [DISCUSS] Proposed Bylaws changes
Date Fri, 15 Feb 2019 18:47:49 GMT
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" <garren@apache.org>
> To: "private@couchdb.apache.org Private" <private@couchdb.apache.org>, "Joan Touzet"
<wohali@apache.org>
> Cc: "CouchDB Developers" <dev@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 <wohali@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" <rnewson@apache.org>
> > > To: "Joan Touzet" <wohali@apache.org>
> > > Cc: "CouchDB Developers" <dev@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 <wohali@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" <rnewson@apache.org>
> > > >> To: "CouchDB PMC" <private@couchdb.apache.org>
> > > >> Cc: "Joan Touzet" <wohali@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 <jan@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 <wohali@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/
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >
> 

Mime
View raw message