community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <>
Subject Re: Vetoes for New Committers??
Date Wed, 29 Mar 2017 13:11:59 GMT
Applying the 'consensus', (or rather the 'every thing must be discussed
first') aspect everywhere is equally tyrranical.

Hence the existence of the simple majority vote (50% of votes cast, + 1
with a min of 3 votes) for procedural matters. And onboarding new
committers, members, officers, etc. is a procedural matter. Unless, of
course, explicitly defined in bylaws.

A -1 is nothing more than an expression of a viewpoint. Without all the
And it seems to me that all the rhetoric viewpoints brought forward in such
discussion about why a certain (non-privileged) contributor should not be
enabled to do more is also a means to deflect from one own imperfection
and/or distrust towards the other.

As an example of such: recently a discussion was brought forward in
general@incubator.a.o. regarding the Log4cxx project (returning it to the
Logging Services project). As I learned from that thread, it seemed that it
was brought forward as a podling because PMC Members on the Logging project
were incapable of having the faith that contributors would work solely on
code belonging to that part of the repo. But that it was feared that they
would work on other code as well after being invited to get the commit bit.
How pityfull (and in my book how not the Apache Way) that a group of people
voted to have such a group of commited contributors (in a way) expelled
from a project and build a successfull community in the incubator project.
Only to discover that such wouldn't happen and the podling reverting to
project it originated from. What a waste of effort and time of many

Anyway, the CouchDb variant is equally valuable regarding the principles of
the Apache Software Foundation. And I do hope that projects will adopt them.

Best regards,

Pierre Smits

OFBiz based solutions & services

OFBiz Extensions Marketplace

On Wed, Mar 29, 2017 at 2:13 PM, Marvin Humphrey <>
> This is a key aspect of Apache community success. We use consensus
> decision making to avoid tyranny of the majority. Majority rule
> alienates the losing party. Consensus has beneficial effects in terms
> of forcing the majority to account for minority opinions, thus keeping
> the community unified.
> Most PMCs do not draft their own rules, and just use "at least 3 +1
> with no vetoes". CouchDB's majority-rule for committers is unusual. I
> hope that CouchDB's bylaws are not adopted as a template for others,
> as I believe that the rule on committer voting is counter to an
> important institutional tradition in Apache governance.
> Occasionally you reach an impasse where someone is holding out and
> consensus cannot be reached. At that point, I've seen communities
> define a specific supermajority threshold instead of requiring "3 +1
> with no vetoes".
> In the abstract, it would be nice if the supermajority rule were
> codified on voting.html, giving communities a template for resolving
> the impasse without thrashing. But ultimately, these votes are not
> legally binding and PMCs can be afforded a certain amount of
> flexibility. The Board cares that communities make personnel decisions
> by consensus, but "consensus" has a little give in it.
> (PMC votes on new PMC members are technically recommendations to the
> Board and officially it is the Board that makes decisions on PMC
> composition -- though the Board nearly always follows the PMC
> recommendation. Committer votes do not go through the Board.)
> Marvin Humphrey
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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