> -----Original Message----- > From: Joe Watkins [mailto:pthre...@pthreads.org] > Sent: Saturday, November 19, 2016 6:11 AM > To: Pierre Joye <pierre....@gmail.com> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes > > Morning Pierre, > > That's not what the rules say. > > There will be a one week discussion period. > > Cheers
Joe, Changing the rules should at the very least be as long as the longest discussion period and the highest majority defined in the Voting RFC, and arguably, longer (which I think it should be here). It's really not sensible otherwise - a group with a simple majority could change the voting rules to require only a simple majority for everything, and pass whatever RFC it wants with a simple majority. Changing the rules is bigger than any single language-level decision, as it effects all future decisions going forward. The original Voting RFC was rushed, and we're all still suffering from the consequences many years later. There's really no need to do it again. Regarding the substance of the RFC, I think Andrea and perhaps others touched on an issue - a 2/3 majority doesn't make sense for situations when we need to pick an option, when none of the options has any inherent bias towards them. When we deal with features, we did define a bias-for-status-quo, which means a 2/3 majority is needed to change it. I agree that the definition of 'features that change the language' is a poorly phrased one (file under 'rushed'), and that other types of features should also be passed in a 2/3 vote. However, there are decisions which really boil down to nothing more than an opinion, where even if the status quo exists or is implied - there's no inherent difference between the choices. For example, the decision on how to version PHPNG that we faced about a year and a half ago. Should '7' have required a 2/3 majority, because '6' is the perceived default? I would disagree. It's a simple matter of opinion, doesn't change the language in any way, and 6 isn't more 'status quo' than 7 in any way that 7 is more than 6. Also, other administrative decisions, such as delaying a release for whatever reasons (like we did for the inclusion of OPcache, IIRC) - should also be a simple majority. I think the test that Michael brought up - "does it have any backwards compatibility or forwards compatibility implications?", is probably the right one to have. In other words - if it breaks BC, it requires a supermajority. If it adds something that, if removed/changed in the future, would introduce BC - it requires supermajority. Otherwise - it's a simple majority (>50%, or even just the option that got the most votes in case of a 3-way or 4-way vote). On top of that, to clarify, the rules themselves should definitely require supermajority to change (arguably higher than the current 2/3 we have; the original Voting RFC was passed in consensus). Zeev
