RE: [PHP-DEV] Proposal to increase the required majority for all RFCs

I don't think that solves our problem. For language changes - which are really new/altered features - 2/3 is sufficient. Another thing which probably makes sense is a 2/3 vote for changing the voting rules - right now there's a bit of a loophole there :) I think for things like new features in or modifications to extensions or functions, changing release dates, version numbers, etc. - 50%+1 is sufficient. There's no major 'interruption to the status quo' and it's more of a matter of opinion, and there's therefore no need for bias towards that status quo. Implementation changes don't fit in this RFC process too well. Implementation changes should be dealt with by those who own the implementation. In this case, it would make sense for people with Zend/TSRM karma to vote, but less so phpdoc or even pecl. If there was an RFC about a change for an implementation change in how we do docs (with no meaningful impact on users) - then similarly, it should be voted on only by people with phpdoc karma. I'm honestly not so sure that such changes even make sense for the RFC process at all, but if we decide to run everything by that process, that's roughly how it should work. One way would be enforcing it; But I think it'd be more appropriate if implementation RFCs were clearly marked as such, clearly defined the component(s) in question, and people figure out themselves whether this is something they should vote over or not. In the case of the 64-bit patch RFC, it'd probably be split to 2 or 3 separate RFCs. One that deals with the user-impacting elements (integer size) - which should obviously involve everyone. On the other extreme end - the parts of the patch that deal with the low-level data structures of the engine that are of no concern to anybody but the engine developers, like the hashtable and bucket size elements - which should involve people with Zend/ karma. And perhaps, something in between - the parts which affect not just the engine but the APIs (macro renames, etc.) - which should be open to people with php-src/ and pecl/ karma. Simply pushing up the required majority for everything to 2/3 will not truly solve the problem IMHO. It would prevent decisions (with no long-term effects) from passing, and it may still allow for groups seeing their implementation forced to undergo a change by people who are neither involved in its maintenance nor affected by the changes. Zeev > -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Saturday, May 17, 2014 9:57 PM > To: PHP internals > Subject: [PHP-DEV] Proposal to increase the required majority for all RFCs > > 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]. > > 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. > > There is not yet an RFC for this, as I want to discuss the concept first. I'd also > rather not talk about other aspects of voting reform in this thread if possible, > such as waiting periods or what karma is needed to vote, so I would ask that you > please make a separate thread for that. > > Thanks! > > [0] irc://irc.efnet.org/#php.pecl > [1] https://wiki.php.net/rfc/voting > -- > Andrea Faulds > http://ajf.me/ > > >