Hi, On Thu, Dec 4, 2014 at 6:28 PM, Alex Harui <aha...@adobe.com> wrote: > ...the reason our guidelines require consensus for adding > people is because of this document [1] and some advice from other > experienced non-Flex Apache people that having consensus for adding folks > is important...
I agree if consensus means "widespread agreement" but in this PMC's guidelines it seems to mean "unanimity". That meaning is definitely against [1] where the first paragraph says "one of the fundamental aspects of accomplishing things within the Apache framework is doing so by consensus". The word consensus at [1] clearly points to the "widespread agreement" variant of http://en.wiktionary.org/wiki/consensus. So by redefining that in your guidelines you have created a variant of the standard Apache understanding of that word, which can be confusing to outsiders, like myself when I subscribed back to this list a few days ago. Back to vetoes - as I said, my recommendation is to take -1s into account *at the community level* when voting in new committers for example. So in general if someone says -1 try to find out what's behind that and act accordingly. And usually don't proceed - but there's no obligation for the PMC. So that's different from formally allowing such -1 to block committer election or other votes, releases etc. That gives people the power to block things even without justification, with potentially bad consequences on the project's well-being. You want things to move forward, even if this means putting some PMC members in a minority sometimes. If that sometimes becomes "always" the community should address that, but "sometimes" is ok for the sake of moving on. When things get difficult, veto power is a very powerful weapon for people who want to show their disagreement or just block things for political reasons. Too powerful actually, so [1] avoids vetoes for most occurences of consensus ("widespread agreement") building. That's why I recommend following the standard Apache rules and recommendations. at [1] And also, as I said, because Flex is a relatively small PMC that can save energy by just sticking to the ASF standard things, without having to spend much time discussing its own variants. But that's just my opinion, there's no obligation for you guys to follow up on that. I just think it might avoid problems in the medium and long term. -Bertrand [1] http://www.apache.org/foundation/voting.html
