Proposal to increase the required majority for all RFCs View as Markdown

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.

Language changes was meant for new features in the language exposed to
the users, things we will have to maintain for ages (think safe_mode
and other new language constructs). Internals on the hand keep
changing without impact on userland, hence we won't have to keep using
one implementation for years.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

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/

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].

I agree that they need to be amended, but....

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.

Requiring a supermajority for every single change wouldn't impede routine
progress, but it would impede meaningful progress. Why? Because it would
essentially prevent us from making a collective decision on any contentious
issue.

Just look at the United States Senate. They can't get anything done
because a 60% supermajority is required on just about everything now that
the filibuster has become routine. It's frustrating when 59% votes in
favor of a routine funding bill and it still fails. What you're talking
about would be an even greater hurdle, 2/3. Now I will concede that,
thankfully, we tend to get along better than members of the U.S. Senate,
but we're still human and we're still going to have heated disagreements on
issues that need to be addressed. If we start having RFCs failing with 65%
in favor of passage, that would have a paralyzing effect and we'd risk
falling into the same trap that befell the Senate.

They weren't always this dysfunctional. It used to be that 60% was only
required for major things with wider implications. Stuff actually got done
back then. Just like stuff gets done now in PHP. If we go to a 2/3-only
model, we'll make it impossible to make any collective executive decisions
on controversial matters. It's arbitrary (why 2/3 and not 60% or 55%?),
ignores the will of the majority, and is simply not sustainable.

A much better solution would be to amend the voting RFC to provide more
clarity as to when 2/3 is required and when it's not. The current language
is too vague and open to interpretation.

--Kris