On 21 March 2015 at 15:24, Pierre Smits <pierre.sm...@gmail.com> wrote:
> 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. > you are right this is the platform to discuss these matters, but you are wrong that there is a policy or principle that the vote for new committers/need to allow a veto. What you refer to is a recommendation ! Is you follow projects you will from time to time see projects forward a suggested PMC extension to the board (Board has to acknowledge every PMC extension, with a 72 hour delay) without having had a vote, but just refer to a consensus thread. So I do not understand the problem, if your PMC wants not to include veto in PMC/Committer go ahead and do so. My personal opinion (my policy or ...) is that if a PMC have had a discussion and then someone gives a -1 in the vote, there is a community problem not a policy problem. > > 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. > Sorry it was not to offend you, but simply to get a better understanding of what the problem really is, as said above if your PMC does not like veto then don´t use it, nobody forces you to use it. If the problem is you want to change the recommendation, then it might be a good idea to talk about a specific change to a specific page. rgds jan I. > > 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 > > >> > > >> > > >
