incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Committer Voting and Vetos
Date Fri, 26 Sep 2014 18:06:03 GMT
On 26 September 2014 19:43, Noah Slater <nslater@apache.org> wrote:

> Another way of wording this would be: the CouchDB community feels that for
> non-technical decisions, a single -1 vote should never block a majority
> consensus. The idea being that if the reasons for the -1 vote were
> compelling enough, others would change their position.
>
> It happened recently on a PMC I sit on. Many people were in favour of an
> action, and one person was against. The action was blocked.
>
> If this happens regularly enough, you can end up never taking any actions.
>
> Of course, how close to absolute consensus you want to require depends on
> two things:
>
> - The nature of the decision
> - The shape of your community
>
> For young projects, I would recommend being strict, and then loosening up
> if you start to have problems.
>
I think this is the key, start strict, and loosen up where really needed as
the project get more mature.

just my 2ct
jan I.

>
>
>
> On Friday, 26 September 2014, Noah Slater <nslater@apache.org> wrote:
>
> > As the primary author of the CouchDB bylaws, I will weigh in here.
> >
> > Agree with Ross on the discussion stuff. We actually codify this
> > attitude in our bylaws.
> >
> > http://couchdb.apache.org/bylaws.html#decisions
> >
> > Specifically, we (CouchDB) see voting as the failure mode of a
> > discussion (a useful one non-the-less), or as a last-step requirement
> > to officiate a particular set of project-level decisions (that are
> > fully enumerated in the bylaws).
> >
> > Wrt to the approval model of voting in committers...
> >
> > cf. http://couchdb.apache.org/bylaws.html#approval
> >
> > We chose lazy 2/3 majority, i.e. requires three binding +1 votes and
> > twice as many binding +1 votes as binding -1 votes.
> >
> > Very specifically (and this is spelled out in the bylaws) with the
> > CouchDB project, we only want a -1 vote to have veto power within the
> > context of code review on a release branch.
> >
> > There are historical reasons for this. We found that some members of
> > our community were casting -1 votes fairly carelessly, and expecting
> > to be able to halt what the majority of the PMC felt were beneficial
> > initiatives (including elections).
> >
> > For us, moving to lazy majority or lazy 2/3 majority for most big
> > decisions was a way to improve our decision-making ability, allowing
> > us to actually make changes to the project, whereas before we had been
> > quite sclerotic.
> >
> > As Joe correctly hits on, some of this was due to me and others
> > attempting to make some fairly large changes to the project since
> > about 2012, when we ran into some major issues.
> >
> > One of the changes I was driving was the redefinition of what a
> > committer is. I wanted to lower the barrier to entry. Whereas before
> > we tended to only elect people who were contributing code, I wanted to
> > expand that and start electing people who were doing other things,
> > like documentation, translation, marketing, design, community
> > management, and so on.
> >
> > This is just one example. But making these sorts of changes
> > (essentially things that require cultural shifts) is hard when one
> > person is able cast a -1 vote and shut down an initiative that
> > everyone else is behind.
> >
> >
> >
> > On 26 September 2014 16:46, Ross Gardler (MS OPEN TECH)
> > <Ross.Gardler@microsoft.com <javascript:;>> wrote:
> > > Trying to build on Joes answer below....
> > >
> > > Given that the ASF is about consensus the vote for.at should be mostly
> > irrelevant. Nominations should have been thoroughly discussed before the
> > vote is called. The vote should be a formality required by the bylaws to
> > demonstrate consensus.
> > >
> > > What I mean is there should never be a veto vote cast. The PMC should
> > have already discussed the reasons why someone has their concerns. Those
> > reasons should either have been supported (and no vote called) or talked
> > through and withdrawn.
> > >
> > > An example... An individual was proposed, the PMC discussed. Two people
> > felt it was too early because the individual had bit contributed much
> code,
> > and thus their code quality could bit be assessed.  Everyone recognized
> the
> > individual was contributing to user support, documentation, design etc.
> In
> > order to have the objections removed a PMC member offered to mentor the
> new
> > committee should code contributions prove to be problematic. This
> approach
> > was agreed, the vote was called and passed.
> > >
> > > That individual is now a member of the foundation. Had we bot brought
> > then in at the earliest opportunity they may never have become so
> invested
> > in the foundation and its projects.
> > >
> > > Sometimes it's not possible to reach unanimous consensus. In such
> > situations the community needs to delay the vote (they agree the concerns
> > are appropriate) or they use voting to break the deadlock. How the vote
> is
> > conducted is covered well by Joe.
> > >
> > > Sent from my Windows Phone
> > > ________________________________
> > > From: Joe Brockmeier<mailto:jzb@zonker.net <javascript:;>>
> > > Sent: ‎9/‎26/‎2014 5:00 AM
> > > To: general@incubator.apache.org <javascript:;><mailto:
> > general@incubator.apache.org <javascript:;>>
> > > Subject: Re: Committer Voting and Vetos
> > >
> > > On Thu, Sep 25, 2014, at 10:59 PM, Alex Harui wrote:
> > >> In a past discussion about by-laws, some folks were adamant that
> voting
> > >> for new committer and PMC members be consensus votes so a single
> person
> > >> can block the adding of a candidate.
> > >>
> > >> Do any projects use some form of majority voting for new committers?
> > >> What are the reasons for allowing vetoes?
> > >
> > > Yes, some projects have lazy majority/no veto for committer votes.
> > > CouchDB for example:
> > >
> > > http://couchdb.apache.org/bylaws.html
> > >
> > > Some reasons I'd give in favor of the veto model:
> > >
> > > * Consensus on decisions around new committers/PMC members is pretty
> > > important. A majority vote that overrides concerns of one or more PMC
> > > members rather than working through those concerns may not be good for
> > > the community.
> > >
> > > * You can usually re-visit a discussion to vote on a new committer or
> > > PMC member, but once they're voted on it's more difficult to undo it.
> If
> > > the no voter(s) are saying "not yet convinced," giving some additional
> > > time to work that out may be better for the community than forcing it
> > > and later regretting it.
> > >
> > > Reason *not* to have a veto:
> > >
> > > * It could be abused, or simply cause harm to a community because one
> or
> > > more PMC members are too conservative about adding new committers.
> > > Contributors lose interest and the community stagnates.
> > >
> > > [Other folks probably have different reasons they'd give in favor of or
> > > against vetoes, many of whom have been around much longer than I -- so
> I
> > > hope others will chime in as well.]
> > >
> > > Generally, I lean towards having a veto. If one member has a real
> > > concern, I'd prefer to see it worked through and achieve consensus
> > > rather than overriding someone.
> > >
> > > Best,
> > >
> > > jzb
> > > --
> > > Joe Brockmeier
> > > jzb@zonker.net <javascript:;>
> > > Twitter: @jzb
> > > http://www.dissociatedpress.net/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > <javascript:;>
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > <javascript:;>
> > >
> >
> >
> >
> > --
> > Noah Slater
> > https://twitter.com/nslater
> >
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message