On Sat, Jan 30, 2016 at 6:34 PM, Andrea Faulds <a...@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! >
I'm definitely in favor of requiring a 2/3 majority in all cases. An RFC that passes with 51:50 votes is clearly not an RFC that a consensus exists on. On the contrary, it indicates a very controversial change which requires further deliberation. In the end, this change will not have significant impact on how many RFCs we accept. The last time I looked into this, the vast majority of RFCs that passed at all, also passed with 2/3 majority. This will only filter out a few controversial cases. Furthermore requiring a consistent quota for all RFCs will avoid the inevitable bickering that seems to spring up with many "major" RFCs, about whether or not a 2/3 vote is required in a particular instance. For RFCs that are significant, but not clear language changes (like the PHP 7 naming RFC, or the phpng RFC, or the int size RFC), there's always a dozen or two mails in the discussion devoted to this most important of questions. Thanks, Nikita
