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.gard...@microsoft.com> 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:j...@zonker.net>
> Sent: ‎9/‎26/‎2014 5:00 AM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> 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
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Noah Slater
https://twitter.com/nslater

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to