Majority voting, regarding on and offboarding of people, is less subject of abuse - when it comes to get to a resolution - than the veto mechanism.
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 4:26 PM, jan i <j...@apache.org> wrote: > 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 > > > >> > > > >> > > > > > >
