Again, this is not about the veto mechanism for the technical works of the project. This is about onboarding of new people, this is about community development.
Voting is not a technicality or formality when it comes to people. It is the ultimate means to get to a resolution. We can discuss all we want, but there are times when discussing doesn't lead to some kind of resolution (consensus or implicit acceptance). When the discussion heats up, it often leads to 'I am right and you are wrong' to and fro. When that happens voting will bring a resolution. But then a veto is the ultimate 'my way and I won't budge' variant in stead of seeking the compromise. In the case of people (both onboarding and offboarding) it doesn't help to move a project forward. It is a postponer, a show stopper. In a posting above it said that the PMC of a project is free to define it own ruleset regarding the way that project operates. But that freedom is bound by the principles of the Apache Software Foundation. Principles (and changes thereon) that are voted upon by the members of the ASF. This platform is the place to discuss the aspects of community development in a broader sense. Like we did when the topic of the project maturity model came up. This is another topic in that broader sense of building mature projects. Why the need to talk specifics? This is not about finger pointing or naming and shaming. And if it were, it shouldn't be done here but in a private message to the board. And I trust that the board has ample means to take appropriate actions. 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 2:42 PM, Mike Kienenberger <mkien...@gmail.com> wrote: > 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 > >> > >> >
