FAQ
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/

Search Discussions

  • Pierre Joye at May 17, 2014 at 7:22 pm

    On Sat, May 17, 2014 at 8:57 PM, Andrea Faulds wrote:
    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
  • Zeev Suraski at May 17, 2014 at 7:46 pm
    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
    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/

  • Andrea Faulds at May 17, 2014 at 7:51 pm

    On 17 May 2014, at 20:46, Zeev Suraski wrote:

    Implementation changes don't fit in this RFC process too well.
    Implementation changes should be dealt with by those who own the
    implementation.
    I don’t and can’t agree with this. Zend changes will ultimately affect everyone.

    It is not just Zend maintainers who’ll be affected by the 64-bit patch, for example. Everyone would, as it would increase PHP’s memory usage.

    Also, I am unconvinced that just because the people who maintain Zend (say) want something, that they are necessarily right.
    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at May 17, 2014 at 8:22 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Saturday, May 17, 2014 10:51 PM
    To: Zeev Suraski
    Cc: PHP internals
    Subject: Re: [PHP-DEV] Proposal to increase the required majority for
    all RFCs
    On 17 May 2014, at 20:46, Zeev Suraski wrote:

    Implementation changes don't fit in this RFC process too well.
    Implementation changes should be dealt with by those who own the
    implementation.
    I don't and can't agree with this. Zend changes will ultimately affect everyone.
    It is not just Zend maintainers who'll be affected by the 64-bit patch, for
    example. Everyone would, as it would increase PHP's memory usage.
    In (the unlikely) case that Zend/ maintainers decide to do something that
    negatively affects PHP - in this case memory usage - then it becomes
    everyone's problem and everyone's entitled to a vote. But not before the
    Zend/ maintainers see the implementation-only (feature-free) patch
    suitable for inclusion in the engine, which wouldn't have happened here.
    Similarly, if the docs guys decide to switch to another platform but the
    generated docs remain unchanged - it's their and only their decision. If
    as a part of that change then suddenly docs suddenly have bloated HTML
    that takes 500MB of memory to render, then it's everyone's vote.

    FWIW, rest assured this is purely theoretical matter. In 15+ years, I
    don't think there was a single patch condoned by the Zend/ maintainers
    that negatively affected performance without otherwise bringing tangible
    value (typically in the form of new features, which are now voted on by
    everyone). It's always the opposite - in a nutshell, Zend/ maintainers
    are crazy for performance. And I'm sure the doc team wouldn't move to a
    tool that emits such poor HTML either.

    Zeev
  • Pierre Joye at May 17, 2014 at 8:25 pm

    On Sat, May 17, 2014 at 9:50 PM, Andrea Faulds wrote:
    On 17 May 2014, at 20:46, Zeev Suraski wrote:

    Implementation changes don't fit in this RFC process too well.
    Implementation changes should be dealt with by those who own the
    implementation.
    I don’t and can’t agree with this. Zend changes will ultimately affect everyone.

    It is not just Zend maintainers who’ll be affected by the 64-bit patch, for example. Everyone would, as it would increase PHP’s memory usage.

    Also, I am unconvinced that just because the people who maintain Zend (say) want something, that they are necessarily right.
    Cannot agree more here. php4 to php5 and the later versions have
    clearly show Zend blocking features that have beeb implemented later,
    loosing years in the process. RFCs provide a way to reach consensus
    and keep in touch with the reality of the PHP needs today and
    tomorrow.


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at May 17, 2014 at 8:36 pm
    I think that the serious core changes require technical expertise before
    voting (like Nikita made).
    And the results of such expertise should be published in additional to RFC
    on the same page.

    Thanks. Dmitry.


    On Sat, May 17, 2014 at 11:50 PM, Andrea Faulds wrote:

    On 17 May 2014, at 20:46, Zeev Suraski wrote:

    Implementation changes don't fit in this RFC process too well.
    Implementation changes should be dealt with by those who own the
    implementation.
    I don’t and can’t agree with this. Zend changes will ultimately affect
    everyone.

    It is not just Zend maintainers who’ll be affected by the 64-bit patch,
    for example. Everyone would, as it would increase PHP’s memory usage.

    Also, I am unconvinced that just because the people who maintain Zend
    (say) want something, that they are necessarily right.
    --
    Andrea Faulds
    http://ajf.me/





    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at May 17, 2014 at 8:42 pm

    On Sat, May 17, 2014 at 10:36 PM, Dmitry Stogov wrote:
    I think that the serious core changes require technical expertise before
    voting (like Nikita made).
    And the results of such expertise should be published in additional to RFC
    on the same page.
    So basically, based on what you say, many if not all new features in
    5.4 or 5.5 would have been rejected per se because they were done by
    new developers.

    Sorry, I rather prefer to keep things like they are and improve/solve
    confusing wording instead of going back to the benevolent dictators
    time.


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at May 17, 2014 at 8:47 pm
    All developers make mistakes and they need to be verified by experts.
    In most cases this process must lead not to rejection but to a better
    solution.

    Thanks. Dmitry.



    On Sun, May 18, 2014 at 12:42 AM, Pierre Joye wrote:
    On Sat, May 17, 2014 at 10:36 PM, Dmitry Stogov wrote:
    I think that the serious core changes require technical expertise before
    voting (like Nikita made).
    And the results of such expertise should be published in additional to RFC
    on the same page.
    So basically, based on what you say, many if not all new features in
    5.4 or 5.5 would have been rejected per se because they were done by
    new developers.

    Sorry, I rather prefer to keep things like they are and improve/solve
    confusing wording instead of going back to the benevolent dictators
    time.


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at May 17, 2014 at 8:50 pm

    On Sat, May 17, 2014 at 10:47 PM, Dmitry Stogov wrote:
    All developers make mistakes and they need to be verified by experts.
    In most cases this process must lead not to rejection but to a better
    solution.
    Indeed, and things are getting better lately :)

    We see RFCs from teams, new developers guided from more experienced
    ones. This is the way to go.

    But closing the doors to a small group of persons, with some of them
    not contributing anything since quite some time, cannot work.

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Stas Malyshev at May 17, 2014 at 8:49 pm
    Hi!
    Also, I am unconvinced that just because the people who maintain Zend
    (say) want something, that they are necessarily right.
    Nobody is "necessarily right". If we could find a person who is always
    right, we wouldn't need a vote - we'd just ask him (or her) and do as he
    (or her) says. Instead, we have to try and find the right thing knowing
    that everybody could be wrong, both individually and collectively.

    And here we have a conundrum - who is likely to be right and wrong on
    the matters dealing with deep engine implementation and requiring deep
    expertise to get them right - people actually working with it or people
    that, without diminishing their respective abilities and capabilities,
    do not?
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Kris Craig at May 17, 2014 at 11:48 pm

    On Sat, May 17, 2014 at 11:57 AM, Andrea Faulds wrote:

    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
  • Guilhermeblanco at May 18, 2014 at 5:02 am
    My vote is for 66%+1 on engine and/or language changes and 50%+1 on side
    changes.
    If I want to suggest a Jsonable interface which purely affects a subset of
    functions and nothing else, I don't think 66% is needed for change to go in.

    My 2¢,

    On Sat, May 17, 2014 at 7:48 PM, Kris Craig wrote:
    On Sat, May 17, 2014 at 11:57 AM, Andrea Faulds wrote:

    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


    --
    Guilherme Blanco
    MSN: guilhermeblanco@hotmail.com
    GTalk: guilhermeblanco
    Toronto - ON/Canada
  • Ferenc Kovacs at May 18, 2014 at 9:06 am

    On Sun, May 18, 2014 at 7:02 AM, guilhermeblanco@gmail.com wrote:

    My vote is for 66%+1 on engine and/or language changes and 50%+1 on side
    changes.
    If I want to suggest a Jsonable interface which purely affects a subset of
    functions and nothing else, I don't think 66% is needed for change to go
    in.

    My 2¢,
    this is what I would consider reasonable too, with the extension than any
    removal of existing (and documented) functionallity should also require 2/3
    of the votes.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Kris Craig at May 18, 2014 at 9:10 am

    On Sun, May 18, 2014 at 2:06 AM, Ferenc Kovacs wrote:


    On Sun, May 18, 2014 at 7:02 AM, guilhermeblanco@gmail.com <
    guilhermeblanco@gmail.com> wrote:
    My vote is for 66%+1 on engine and/or language changes and 50%+1 on side
    changes.
    Agreed, except that we need to strengthen the wording by more specifically
    stating what "engine and/or language changes" does and does not mean. It's
    easy to agree on this in principle, but the devil is in the details. Right
    now, there aren't any.

    If I want to suggest a Jsonable interface which purely affects a subset of
    functions and nothing else, I don't think 66% is needed for change to go
    in.

    My 2¢,
    this is what I would consider reasonable too, with the extension than any
    removal of existing (and documented) functionallity should also require 2/3
    of the votes.
    Also agreed.

    --Kris

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 17, '14 at 6:57p
activeMay 18, '14 at 9:10a
posts15
users8
websitephp.net

People

Translate

site design / logo © 2022 Grokbase