couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reddy B. <redd...@live.fr>
Subject RE: [DISCUSS] Proposed Bylaws changes
Date Sun, 17 Feb 2019 18:51:20 GMT
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 <wohali@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" <rnewson@apache.org>
> To: dev@couchdb.apache.org
> Cc: "private@couchdb.apache.org Private" <private@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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message