Re: Should we rethink the 50%+1 requirement for non-"language changes"?

As someone who has never participated with intervals before and only just recently subscribed to the list, I would like to see a minimum percentage of voting members participating in a vote for something to pass. In my interpretation of the current rules, a measure could pass with only 3 votes cast (2 for / 1 against). In fact, there was a recent proposal that passed with only 11 votes cast. If that few of voting members are participating, maybe the proposal wasn't clear enough (or maybe it's just not needed at all)? Sure you can argue that they had ample time to discuss, but I would say perhaps they just saw no value in it. If a proposal isn't offering enough value for the greater community, maybe it doesn't belong in core and should be either a pecl extension or userland code? Joe Constant On Jan 30, 2016, at 10:34 AM, Andrea Faulds <ajf@ajf.me> wrote: Hi everyone, The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC process again. Under the Voting RFC[2], "Language changes" (in practice, changes to syntax and semantics) require at least a 2/3 majority to pass when they come to a vote, whereas changes that don't fall under that category require a mere plurality of more Yes votes than No votes, aka "50%+1". The stated justification for the 2/3 requirement is that such changes are more permanent and shouldn't be arbitrary. However, there's no justification given for why other RFCs *shouldn't* receive the same level of scrutiny. Consider that the language, in practice, is not simply the syntax and semantics specified by the language specification and implemented by the Zend Engine or HHVM. PHP's bundled extensions are also an important part of PHP which define the language: an implementation of PHP which lacked them would not be very useful for running real PHP applications, and it is only with considerable difficulty that you could write PHP code without them. In fact, certain key primitive operations on PHP's built-in datatypes are only exposed through functions in ext/standard! And yet, RFC votes on changes to the extensions are held to a lesser standard than changes to the syntax. Another thing to consider is the types of changes that RFCs propose. These are usually used for changes that should not simply get in through consensus around a pull request. This can range from simply adding new functions, to making backwards-incompatible changes. These are not decisions to be taken lightly. Finally, I think that a proposal that is good enough will have no trouble achieving a 2/3 majority anyway. In practice, many RFCs pass by unanimous vote! So, would there be support for raising the passing threshold for non-"language changes" to 2/3? At the very least, I think we should have this for backwards-incompatible changes. If there's enough support, I'll write an RFC, though I'll have to figure out how exactly to change the rules. (Can the voting RFC be amended by another RFC? The RFC process isn't a good fit for procedural things like this.) Thanks! [1] https://wiki.php.net/rfc/openssl_aead [2] https://wiki.php.net/rfc/voting -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php