Re: Proposal to increase the required majority for all RFCs

My vote is for 66%+1 on engine and/or language changes and 50%+1 on side changes. If I want to suggest a Jsonable interface which purely affects a subset of functions and nothing else, I don't think 66% is needed for change to go in.. My 2¢, On Sat, May 17, 2014 at 7:48 PM, Kris Craig <kris.craig@gmail.com> wrote: > On Sat, May 17, 2014 at 11:57 AM, Andrea Faulds <ajf@ajf.me> wrote: > > > Good evening, > > > > Given the recent controversy on the 64-bit patch vote, and after some > > discussions on IRC[0] with some others, I think we should amend the > current > > voting rules[1]. > > > > I agree that they need to be amended, but.... > > > > > > Currently only 50%+1, a simple majority, is required to pass > ‘non-language > > changes’. However, I feel that this is too small of a hurdle to pass. > Under > > this rule, contentious changes can pass despite a very thin majority. The > > rationale seems to be that non-language changes have less broad effect > and > > hence don’t need wide approval. However, changes which don’t affect the > > ‘language’ can still have wide-ranging effect and be very problematic. It > > is also a quite vague requirement, as it is not always clear what change > > affects the ‘language’ and what doesn’t. > > > > Hence, I propose that we require a supermajority of 2/3 to pass RFC > votes. > > This system is currently used for ‘language’ votes, but I feel it ought > to > > extend to everything. This a much bigger hurdle to climb over than only a > > simple majority, but it means that only changes with broad consensus are > > likely to pass. It also means that the results of a vote will be less > > contentious, as there need to be at least twice as many votes in favour > > than against for it to pass. Finally, this change would mean there would > be > > no interpretation issues as to what constitutes a language change, as all > > changes must meet the same bar. > > > > To those who say this might impede progress, I would like to point out > > that every single RFC accepted for PHP 5.6 so far was accepted by more > than > > a 2/3 majority, and so would not have been stopped by this hurdle. Also, > > I’m not sure it is fair if ‘progress’ happens when there is not broad > > consensus on an issue. > > > > Requiring a supermajority for every single change wouldn't impede routine > progress, but it would impede meaningful progress. Why? Because it would > essentially prevent us from making a collective decision on any contentious > issue. > > Just look at the United States Senate. They can't get anything done > because a 60% supermajority is required on just about everything now that > the filibuster has become routine. It's frustrating when 59% votes in > favor of a routine funding bill and it still fails. What you're talking > about would be an even greater hurdle, 2/3. Now I will concede that, > thankfully, we tend to get along better than members of the U.S. Senate, > but we're still human and we're still going to have heated disagreements on > issues that need to be addressed. If we start having RFCs failing with 65% > in favor of passage, that would have a paralyzing effect and we'd risk > falling into the same trap that befell the Senate. > > They weren't always this dysfunctional. It used to be that 60% was only > required for major things with wider implications. Stuff actually got done > back then. Just like stuff gets done now in PHP. If we go to a 2/3-only > model, we'll make it impossible to make any collective executive decisions > on controversial matters. It's arbitrary (why 2/3 and not 60% or 55%?), > ignores the will of the majority, and is simply not sustainable. > > A much better solution would be to amend the voting RFC to provide more > clarity as to when 2/3 is required and when it's not. The current language > is too vague and open to interpretation. > > --Kris > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada