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
