On 26 September 2014 19:43, 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. > 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 <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 >
