Have you read https://www.apache.org/foundation/voting.html?
As others have said, the idea is always to build consensus rather than force a result. I guess I've been fortunate in that the projects in which I've been most active have always been more interested in consensus than individuals forcing a result. This does add what seems to be a bit of bureaucracy at first glance. For example, we "vote" about taking a vote for committers and PMC members (others above have called it "DISCUSS"). And if we aren't going to be unanimous in our decision to add in a new committer or PMC member, then we've always decided to postpone the vote until the individual overcomes whatever caused the objection. I think the reason that code commits can be vetoed is to prevent dangerous situations. Projects can't afford to delay dealing with security issues or licensing issues. I've been on the PMC for two different projects for a decade, and to my recollection we've never had a code veto. As far as I know, there's only been a threat of a veto one time in those 20 project-years of time, and it was by me. I used the threat of veto with a specific committer who had been asked before to not make behavioral changes to the code in the same commit where he reformatted every line of the file. It was making it impossible to review his code changes. Veto is there for emergencies, not for bending others to your technical vision. And yes, we've had some disagreements about how things should be done technically, but the final decision usually came down to either "I'm willing to do the work" or putting it on hold. On Sat, Mar 21, 2015 at 7:00 AM, Pierre Smits <pierre.sm...@gmail.com> wrote: > If the majority perceives that a nominee is an obstructionist then it will > be reflected in the voting result. But if the minority - or even only one > voter - perceives that and others don't, then a veto would be a show > stopper for innovation, expansion and merit recognition c.q. privilege > awarding. > > I wonder how it can be that democracy is perceived worse than any other > cracy when it comes to people in open source projects in general and ASF > projects in particular. Mature projects shouldn't need to have such a > mechanism when it comes to people. And it doesn't seem to fit in he Apache > Way. > > Best regards > > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Sat, Mar 21, 2015 at 5:24 AM, Alex Harui <aha...@adobe.com> wrote: > >> Consensus Approval works great until you have someone who others rightly >> or wrongly perceive as an obstructionist. Then it just makes the whole >> project the loser. >> >> At least one project uses majority approval for new members, but a serious >> attempt is made to make sure that the vote is unanimous anyway. Those in >> opposition deserve to be listened to, but if there are only one or two >> against and lots more in favor, then majority approval avoids long threads >> trying to persuade the one or two. Sure discussing more to achieve >> Consensus can be better, but you can also lose momentum of the committer >> candidate and momentum of the rest of the community. >> >> The -1 vote is an alluring drug. It can be misused by individuals who, >> consciously or not, cannot avoid the temptation to have control rather >> than to collaborate. But really make sure you listen. History is full of >> disasters caused by not listening to that one person. >> >> -Alex >> >>
