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

Den 2016-01-30 kl. 18:34, skrev Andrea Faulds:

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

I'm thinking on RFC's that are: - Not technically advanced and/or - Provides value in making life easier for programmer and/or - Belongs to ext with small audience and/or - Is a small feature Would they benefit from this proposal or would it lead to that certain categories of RFC's would never pass? In the OPENSSL case it would have lead to a not pass. Judging from the discussion it didn't seem like there was resources to make a bigger thing, meaning that this small addition would not be part of PHP in the the short to medium-term perspective. Regards //Björn Larsson