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 rhetoric! 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 involved. 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 ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Mar 29, 2017 at 2:13 PM, Marvin Humphrey <mar...@rectangular.com> wrote: > > 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: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
