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.
From: Andrea Faulds
Sent: Saturday, May 17, 2014 9:57 PM
To: PHP internals
Subject: [PHP-DEV] Proposal to increase the required majority for all RFCs
Given the recent controversy on the 64-bit patch vote, and after some
discussions on IRC with some others, I think we should amend the current
Currently only 50%+1, a simple majority, is required to pass
changes'. However, I feel that this is too small of a hurdle to pass.
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
requirement, as it is not always clear what change affects the
Hence, I propose that we require a supermajority of 2/3 to pass RFC
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.
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.