Understand there is a radical difference between majority, consensus and unanimity. The HTTP Server project has successfully operated by unanimity, although many of us have experience of having the single holdout block progress.
I don't believe majority is sufficient in these sorts of matters. In most projects, contributors are part of one or two major organizational players. That vocal minority protects a valued third voice. But an intractable project member is also an issue. If you are looking for unanimity in the face of an obstructionist, your choices are to move toward plurality or consensus ... or drop an obstructionist from the PMC roster. The HTTP Server PMC has succeeded in working through these issues without evicting a project member, and continuing to make progress. Noah Slater <nsla...@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. > > > >On Friday, 26 September 2014, Noah Slater <nsla...@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.gard...@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:j...@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 >> > j...@zonker.net <javascript:;> >> > Twitter: @jzb >> > http://www.dissociatedpress.net/ >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> <javascript:;> >> > For additional commands, e-mail: general-h...@incubator.apache.org >> <javascript:;> >> > >> >> >> >> -- >> Noah Slater >> https://twitter.com/nslater >> > > >-- >Noah Slater >https://twitter.com/nslater
