Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Abolish 50%+1 Votes »

[RFC] Abolish 50%+1 Votes

php.internals

Joe Watkins

9 years ago
Afternoon internals, This has been discussed before in various RFC threads, there does seem to be some consensus that 50%+1 votes could be harmful. To what degree, I am not sure. I raise for discussion the topic of abolishing 50%+1 votes, and requiring all changes regardless of their nature to pass by a super majority of 2/3+1. Please read the (brief) RFC and raise objections here. There will be a one week discussion period for this RFC. Cheers Joe

Dennis Clarke

9 years ago
On 11/17/2016 12:18 PM, Joe Watkins wrote:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful. > > To what degree, I am not sure. > > I raise for discussion the topic of abolishing 50%+1 votes, and requiring > all changes regardless of their nature to pass by a super majority of > 2/3+1.
For a language tool as critical as PHP it would be better to consider a larger sample size such as 75%+1. However the merit is the issue and not the mass vote. IMHO. Dennis Clarke

Joe Watkins

9 years ago
Afternoon internals, https://wiki.php.net/rfc/abolish-narrow-margins Cheers Joe On Thu, Nov 17, 2016 at 5:33 PM, Dennis Clarke <dclarke@blastwave.org> wrote:

Joe Watkins

9 years ago
Afternoon internals, https://wiki.php.net/rfc/abolish-narrow-margins Cheers Joe On Thu, Nov 17, 2016 at 5:18 PM, Joe Watkins <pthreads@pthreads.org> wrote:

Yasuo Ohgaki

9 years ago
Hi Joe, On Fri, Nov 18, 2016 at 2:53 AM, Joe Watkins <pthreads@pthreads.org> wrote:
> > https://wiki.php.net/rfc/abolish-narrow-margins
Requiring 2/3 majority is reasonable. I'll vote yes for this if people who are not in favor disclose the reason why. Just voting "no" for a RFC is not constructive. Improving a RFC is difficult without reason why it is not preferred. Decision could be based on wrong assumption and/or misunderstanding sometimes. Could we have comment plugin for this? It does not have be to a comment plugin, if there is better plugin for the purpose. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Christoph Becker

9 years ago
On 18.11.2016 at 12:05, Yasuo Ohgaki wrote:
> On Fri, Nov 18, 2016 at 2:53 AM, Joe Watkins <pthreads@pthreads.org> wrote: >> >> https://wiki.php.net/rfc/abolish-narrow-margins > > Requiring 2/3 majority is reasonable. > > I'll vote yes for this if people who are not in favor disclose the > reason why. Just voting "no" for a RFC is not constructive. Improving > a RFC is difficult without reason why it is not preferred. Decision > could be based on wrong assumption and/or misunderstanding sometimes. > > Could we have comment plugin for this? It does not have be to a > comment plugin, if there is better plugin for the purpose.
We may consider to customize the doodle plugin[1]. IIRC, it is alread customized and the original is unmaintained, so there won't be update issues. [1] <https://github.com/php/web-wiki/tree/master/dokuwiki/lib/plugins/doodle>
-- Christoph M. Becker

Joe Watkins

9 years ago
Afternoon Yasuo, Maybe, it is our fault - the person who created the RFC. In an ideal world, during discussion you should collect legitimate unresolved objections, and have those as "no" options on the vote. If when it came to vote time, the options were: Yes No because X No because Y No because Z No I think most people would be happy to provide a reason, if you have it listed. It should be listed, because it should have been brought up during discussion. Obviously we don't live in an ideal world, and you may get lots of no votes still that don't provide a reason. But it doesn't need to be ideal to give us some clue of where to take the RFC next. Many people don't like the idea of requiring a reason, but I'm sure the same people would provide one if it were listed as a voting option. What they don't want is to have to constantly defend their decision after it's been made, which is in some sense reasonable. Cheers Joe On Fri, Nov 18, 2016 at 11:05 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

Yasuo Ohgaki

9 years ago
Hi Joe, On Sat, Nov 19, 2016 at 12:28 AM, Joe Watkins <pthreads@pthreads.org> wrote:
> I think most people would be happy to provide a reason, if you have it > listed. > It should be listed, because it should have been brought up during > discussion. > > Obviously we don't live in an ideal world, and you may get lots of no votes > still that don't provide a reason.
There are clear cases that people misunderstand proposals. Recent example is PRNG adoption for uniqid(). I proposed patch does not have any BC, but there were people opposed based on false FUD. i.e. RPNG device access causes access error which is _nothing_ to do with internal function. Another example is session ID validation. It is mandatory to keep session as secure as possible, yet there are some people do not realize(?) why it is mandatory. There is workaround, but I haven't seen implementation does it correctly. I would rather just fix the issue rather than trying to teach how to do it. Anyway, regardless of opposition is reasonable or not, disclosing the reason why it is not preferred is valuable. Could you at least state in the RFC that all voters who are not in favor of the proposal should disclose the reason? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Marcio Almada

9 years ago
2016-11-18 22:10 GMT-04:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:
> Hi Joe, > > On Sat, Nov 19, 2016 at 12:28 AM, Joe Watkins <pthreads@pthreads.org> > wrote: > > I think most people would be happy to provide a reason, if you have it > > listed. > > It should be listed, because it should have been brought up during > > discussion. > > > > Obviously we don't live in an ideal world, and you may get lots of no > votes > > still that don't provide a reason. > > There are clear cases that people misunderstand proposals. > > Recent example is PRNG adoption for uniqid(). I proposed patch does > not have any BC, but there were people opposed based on false FUD. > i.e. RPNG device access causes access error which is _nothing_ to do > with internal function. > > Another example is session ID validation. It is mandatory to keep > session as secure as possible, yet there are some people do not > realize(?) why it is mandatory. There is workaround, but I haven't > seen implementation does it correctly. I would rather just fix the > issue rather than trying to teach how to do it. > > Anyway, regardless of opposition is reasonable or not, disclosing the > reason why it is not preferred is valuable. Could you at least state > in the RFC that all voters who are not in favor of the proposal should > disclose the reason? > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Hi Yasuo, In my opinion, this belongs to another RFC. Please, propose an optional way for voters to input a small paragraph disclosing a justification upon voting. We've seen many voices on this mailing list supporting this proposal, perhaps it's time to discuss officially. Keep in mind this change in the voting process requires the voting doodle to be customized somehow (I don't know how). Best regards, Márcio.

Alice Wonder

9 years ago
On 11/18/2016 06:26 PM, Marcio Almada wrote:
> > Hi Yasuo, > > In my opinion, this belongs to another RFC. Please, propose an optional way > for voters to input a small paragraph disclosing a justification upon > voting. We've seen many voices on this mailing list supporting this > proposal, perhaps it's time to discuss officially. Keep in mind this change > in the voting process requires the voting doodle to be customized somehow > (I don't know how). > > Best regards, > Márcio. >
Explaining why someone votes against something makes voting against more difficult than voting for. I would suggest just increasing the margin to pass. That's a good way to solve the issue, and the pros and cons can be discussed on the list. Is it required to be a member of this list to vote? That too would be a good idea if it isn't required, hopefully translators are accurate enough to understand arguments here pro and con when not in a language the voter has excellent grasp of. Personally I abstain from voting because I do not feel qualified to make decisions that impact the majority of PHP users, but some things I may comment on, but only on this list.

Kalle Sommer Nielsen

9 years ago
2016-11-19 3:39 GMT+01:00 Alice Wonder <alice@librelamp.com>:
> Is it required to be a member of this list to vote? That too would be a good > idea if it isn't required, hopefully translators are accurate enough to > understand arguments here pro and con when not in a language the voter has > excellent grasp of.
Only people with active VCS accounts or wiki accounts (that's been approved) are allowed to vote.
-- regards, Kalle Sommer Nielsen kalle@php.net

Alice Wonder

9 years ago
On 11/18/2016 06:55 PM, Kalle Sommer Nielsen wrote:
> 2016-11-19 3:39 GMT+01:00 Alice Wonder <alice@librelamp.com>: >> Is it required to be a member of this list to vote? That too would be a good >> idea if it isn't required, hopefully translators are accurate enough to >> understand arguments here pro and con when not in a language the voter has >> excellent grasp of. > > Only people with active VCS accounts or wiki accounts (that's been > approved) are allowed to vote. > > >
Thank you, I knew there was an identity validation requirement, and that makes sense. I do know I enjoy reading the RFC discussions here on what is proposed to be deprecated, it often has helped me realize there is a better way to do something than the way I currently am doing something. mcrypt for example, after reading about how stale it was, I didn't wait to deprecate it on my own but just removed it from my php build - and any web apps I install that want it, I fix.

Christoph Becker

9 years ago
On 17.11.2016 at 18:18, Joe Watkins wrote:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful. > > To what degree, I am not sure. > > I raise for discussion the topic of abolishing 50%+1 votes, and requiring > all changes regardless of their nature to pass by a super majority of > 2/3+1. > > Please read the (brief) RFC and raise objections here. > > There will be a one week discussion period for this RFC.
Thans for the RFC, Joe. I'm all for it, but maybe we should raise the bar even higher (say, 75% as suggested by Dennis), and perhaps also introduce a required minimum of votes (to avoid that a single yes vote could decide over an RFC). Anyhow, I would suggest to rewrite the introduction section – a PHP RFC should better be concerned with PHP only. :-)
-- Christoph M. Becker

Joe Watkins

9 years ago
Afternoon Chrisoph, The minimum number of votes is going to be the subject of another RFC, let's leave that aside for now. I've written many RFC's that change the language, the majority have failed. Setting the bar high is the aim, and the bar feels high at 2/3+1, but crucially, not higher than it should be. Setting the bar too high is discouraging, I think: We don't want less contributions, we want clearer outcomes. Cheers Joe On Thu, Nov 17, 2016 at 5:57 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:

Rowan Collins

9 years ago
On 17/11/2016 18:03, Joe Watkins wrote:
> Afternoon Chrisoph, > > The minimum number of votes is going to be the subject of another RFC, > let's leave that aside for now.
I'm not sure splitting this into lots of micro-decisions is wise: why not discuss a general reform of the voting system, and have a single RFC which can then document the agreed system, and supersede https://wiki.php.net/rfc/voting? This could then include: 1) Clarifying who exactly can vote; the current definition is very vague, and allows for wildly differing numbers of votes, making the next two points much harder. 2) Should there be a "quorum" (minimum number of votes) required for a vote to be passed? 3) What should be the minimum proportion of votes required for a resolution to pass, given the decisions made under 1 and 2. These issues are all interconnected - if you have a large voter base, and a large quorum, then the difference between 50% and 66% is much higher. Regards,
-- Rowan Collins [IMSoP]

Joe Watkins

9 years ago
Afternoon Rowan, The sum of their parts amounts to a substantial change in the way we conduct development here. If we are going to make changes, we should not draw out the process, but nor should we have too much haste in making these decisions. Having a one week discussion period is some kind of compromise between a big RFC, and doing one thing at a time. Let us consider each issue on it's own, make good decisions on each issue, with clear majorities. Cheers Joe On Thu, Nov 17, 2016 at 6:16 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

Rowan Collins

9 years ago
On 17/11/2016 18:23, Joe Watkins wrote:
> The sum of their parts amounts to a substantial change in the way we > conduct development here.
[...]
> Let us consider each issue on it's own, make good decisions on each > issue, with clear majorities.
You seem to take the same basis as me, and reach the opposite conclusion. I think there is substantial interaction between the questions of who should vote, how they should vote, and how the vote should be "won". Changing the process one variable at a time might lead to combinations which would never have been reached in a unified discussion. I realise you've now said you're going to redraft the RFC with wider scope, so I hope you'll consider bringing in some of the other elements raised. Regards,
-- Rowan Collins [IMSoP]

Andrew Faulds

9 years ago
Hi Rowan, Rowan Collins wrote:
> On 17/11/2016 18:03, Joe Watkins wrote: >> Afternoon Chrisoph, >> >> The minimum number of votes is going to be the subject of another RFC, >> let's leave that aside for now. > > I'm not sure splitting this into lots of micro-decisions is wise: why > not discuss a general reform of the voting system, and have a single RFC > which can then document the agreed system, and supersede > https://wiki.php.net/rfc/voting?
This might be a good idea, even if we only change the threshold. A potential problem with our current system of policy RFCs is I don't think can we amend existing ones, only pass new ones. This would mean you'd have to refer to the Voting RFC and the new RFC (as proposed by Joe) to understand the current policy, rather than it all being in one place. Worse, if you just read the Voting RFC on its own, you wouldn't know the threshold it specifies is no longer correct. To compare to legal systems for a moment, they don't have to have this problem. In the UK, we have Acts of Parliament, which pass and become part of the law. But those acts can amend existing Acts that are already part of the law, to keep things neat. That makes things simpler, because when you want to know what the current law is, you only have to refer to the existing Act as amended, not the existing Act and a new Act which supplements and possibly overrides it. You can also of course replace existing Acts entirely, or create new supplementary Acts, but you want to avoid this when making small changes like the one Joe proposes. Creating an RFC which would completely replace the Voting RFC would avoid people having to refer to two RFCs, one of which overrides the other. Alternatively, we could decide to do what the law does, and update the Voting RFC in place once a new RFC passes, so the wiki page for it would reflect the amended rules, not the RFC as it originally passed. This is a wiki, so we do have revision control and could mention on the page that it had been amended, and link to the original version. (This is, incidentally, what the UK's legislation website does.) Regards.
-- Andrea Faulds https://ajf.me/

Joe Watkins

9 years ago
Afternoon Andrea, Intention was to just update the voting page, and any other related docs that might exist (maybe rfc template). Cheers Joe On Thu, Nov 17, 2016 at 6:55 PM, Andrea Faulds <ajf@ajf.me> wrote:

Andrew Faulds

9 years ago
Hi Joe, Joe Watkins wrote:
> Afternoon Andrea, > > Intention was to just update the voting page, and any other related docs > that might exist (maybe rfc template). >
Okay, that's fine. Make sure to mention on the voting RFC that it was amended, then. :)
-- Andrea Faulds https://ajf.me/

Michael Morris

9 years ago
The study of voting systems is a hobby of mine and I've encoding vote gathering algorithms implementing them before, so this gives me a bit of insight into the discussion at hand that I would like to share. The goal of any voting system is to reach a consensus, and while majority rule (regardless of the amount of the majority) is appropriate for most issues, it is not appropriate for all. Specifically, it fails to work in any situation where the group is being asked to reach a consensus on three or more choices. Ironically the choice put forth in this thread is just such an instance. Stay at 50%+1, Go to 2/3rds, 3/4ths has been mentioned and 3/5ths is another commonly required ratio. Four choices. The best method for dealing with this situation is a ranked choice ballot and an instant run off vote. The ballot itself asks the voters to rank their choices, not just stamp a single one. The votes are counted using the expressed first choice on the ballot. If the measure doesn't pass then the option with the fewest supporters is disqualified. The ballots for that option are recounted and the 2nd choice is added to the counts. If the measure still doesn't pass this process is repeated, recursively until there are only two candidate, in which case the one with the majority wins. This method doesn't work directly with methods requiring a plurality other than a simple majority, but it isn't meant to be applied in the same situations. I'm putting this forward because I worry the group might paint themselves into a corner by requiring all issues require a super majority, because that's going to fall apart when there are three or more possibilities. The methods can be combined, using ranked choice to determine which option will be put up against the status quo, then a super majority vote to determine if that option will be chosen over the status quo. ​

Andrew Faulds

9 years ago
Hi, Michael Morris wrote:
> I'm putting this forward because I worry the group might paint themselves > into a corner by requiring all issues require a super majority, because > that's going to fall apart when there are three or more possibilities. The > methods can be combined, using ranked choice to determine which option will > be put up against the status quo, then a super majority vote to determine > if that option will be chosen over the status quo.
This is a fair point. There's also some types of vote (deciding between two ways to implement something which is decided as happening) for which a 2/3 majority doesn't make sense, because it biases it in favour of one outcome.
-- Andrea Faulds https://ajf.me/

Joe Watkins

9 years ago
Morning Micheal, In general, we don't have RFC's that have many choices, nor do we for this RFC. We are only choosing between requiring 2/3's all the time, and not requiring 2/3 all the time. While it has been suggested that we raise the bar higher than our current standards raise it, we won't be choosing between those options at vote time, for the reasons I've already given. I would rather coerce contributors into making simple votes with high standards, than allow them to create very complicated voting options, possibly with lower standards. Cheers Joe On Thu, Nov 17, 2016 at 9:47 PM, Michael Morris <tendoaki@gmail.com> wrote:

Adam Baratz

9 years ago
> > The minimum number of votes is going to be the subject of another RFC, >> let's leave that aside for now. >> > > I'm not sure splitting this into lots of micro-decisions is wise: why not > discuss a general reform of the voting system, and have a single RFC which > can then document the agreed system, and supersede > https://wiki.php.net/rfc/voting? >
I agree with this. We could end up with a different system if we look at this holistically. Also, I'm not sure what the urgency in making this change is. I'd rather be thoughtful about a substantive change like this. It might help to articulate the goals of the voting system. I agree with the gut feel that 50%+1 is a weak test, but that really depends on what's being tested. If we can articulate goals in the RFC, that will also help inform how the community approaches writing RFCs. I have some concerns that a very high bar will make it difficult to change extensions if their users aren't well-represented here. Thanks, Adam

Michael Morris

9 years ago
On Thu, Nov 17, 2016 at 5:33 PM, Adam Baratz <adambaratz@php.net> wrote:
> > > I agree with this. We could end up with a different system if we look at > this holistically. Also, I'm not sure what the urgency in making this > change is. I'd rather be thoughtful about a substantive change like this. > > It might help to articulate the goals of the voting system. I agree with > the gut feel that 50%+1 is a weak test, but that really depends on what's > being tested. If we can articulate goals in the RFC, that will also help > inform how the community approaches writing RFCs. > > I have some concerns that a very high bar will make it difficult to change > extensions if their users aren't well-represented here. > >
My opinion, for what it's worth, is that simple majority should be sufficient for any non-binding decision - that is a choice that doesn't have BC breaks and further doesn't create future BC breaks if the measure is voted out. Simple majority should also be sufficient if there is no status quo other than doing nothing and doing nothing isn't a viable choice. Ranked choice ballots should be used when there are three or more competing plans of action as it is better for reaching consensus in those situations. These rules as well as who has a right to vote need to be more clearly documented somewhere.

Kalle Sommer Nielsen

9 years ago
Hi Joe 2016-11-17 18:18 GMT+01:00 Joe Watkins <pthreads@pthreads.org>:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful.
I still stand by that we should only let active contributors to PHP vote, while I understand that not everyone votes and there are many projects within the PHP.net umbrella. I do understand that many from outside projects wants to contribute and not everyone is great at C or internals or similar, but it is us that maintain PHP and if everyone who have a wiki account votes on something they may not understand the implication of, then it us that sits with it for years to maintain. By doing that I think we wouldn't need to have a X%+1 for accepting an RFC, if there are a tie, then there is obviously a dispute among us core developers and it can be discussed. Kinda what we used to do with voting on the ML, just by tracking them on the wiki interface.
-- regards, Kalle Sommer Nielsen kalle@php.net

Joe Watkins

9 years ago
Afternoon Kalle, We have to start with the assumption that everyone that votes, does so with good intentions. I'm sympathetic to the view that active contributors should somehow carry more weight with their words, or vote. But, I shy away from actually saying that we should only listen to those people. Consider the case of an extension developer who may not have time to actively contribute to php-src, but is directly affected by decisions we make. They acquired karma for fixing a couple of bugs in the course of developing their extension, and so vote when RFC's come along that they have an opinion on. Their extension may be widely used, but just not a candidate for inclusion in PHP. I think we all intuitively agree that this person deserves their voice, and that they can't be considered active contributors in any real sense. Such cases are innumerable. Cheers Joe On Thu, Nov 17, 2016 at 5:59 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:

Kalle Sommer Nielsen

9 years ago
2016-11-17 19:22 GMT+01:00 Joe Watkins <pthreads@pthreads.org>:
> Afternoon Kalle, > > We have to start with the assumption that everyone that votes, does so with > good intentions.
Ofcourse, but I just don't think it is fair that someone who made an RFC and never contributed anything else to the project, can have an impact on the future of PHP just because they got a wiki account or someone who got a VCS account for a pear package they never released 10 years ago, but still got approved. I fully respect everyone who have contributed to PHP now and in the past for all their hard work, but I would also like to see a line drawn.
> I'm sympathetic to the view that active contributors should somehow carry > more weight with their words, or vote. But, I shy away from actually saying > that we should only listen to those people.
I agree that we should listen to everyone, else it becomes this closed gentleman's club it kinda used to be. Alternatively we can have a community vote, which can be a factor to the end result ofcourse.
> Consider the case of an extension developer who may not have time to > actively contribute to php-src, but is directly affected by decisions we > make. They acquired karma for fixing a couple of bugs in the course of > developing their extension, and so vote when RFC's come along that they have > an opinion on. Their extension may be widely used, but just not a candidate > for inclusion in PHP. > > I think we all intuitively agree that this person deserves their voice, and > that they can't be considered active contributors in any real sense. > > Such cases are innumerable.
That's a valid case and concern, but I think if it came down to changing to something like active contributors, such cases like this should be well written and how we can let such voices heard/matter, maybe there could be a category, say someone wants to add a new function to an extension, then everyone who contributes to that can vote too (as in karma based) or if its an internal API change that can affect extensions heavily.
-- regards, Kalle Sommer Nielsen kalle@php.net

Niklas Keller

9 years ago
2016-11-17 19:45 GMT+01:00 Kalle Sommer Nielsen <kalle@php.net>:
> 2016-11-17 19:22 GMT+01:00 Joe Watkins <pthreads@pthreads.org>: > > Afternoon Kalle, > > > > We have to start with the assumption that everyone that votes, does so > with > > good intentions. > > Ofcourse, but I just don't think it is fair that someone who made an > RFC and never contributed anything else to the project, can have an > impact on the future of PHP just because they got a wiki account or >
Just a note: People with just wiki accounts can't vote currently: https://wiki.php.net/rfc/voting#who_can_vote Regards, Niklas

Kalle Sommer Nielsen

9 years ago
2016-11-19 12:18 GMT+01:00 Niklas Keller <me@kelunik.com>:
> 2016-11-17 19:45 GMT+01:00 Kalle Sommer Nielsen <kalle@php.net>: >> >> 2016-11-17 19:22 GMT+01:00 Joe Watkins <pthreads@pthreads.org>: >> > Afternoon Kalle, >> > >> > We have to start with the assumption that everyone that votes, does so >> > with >> > good intentions. >> >> Ofcourse, but I just don't think it is fair that someone who made an >> RFC and never contributed anything else to the project, can have an >> impact on the future of PHP just because they got a wiki account or > > > Just a note: People with just wiki accounts can't vote currently: > https://wiki.php.net/rfc/voting#who_can_vote > > Regards, Niklas
Hmm interesting, because I'm certain that in the past I have seen people with just wiki accounts vote. I just had a look but I couldn't find any such by browsing a few RFCs, maybe these records were removed at one point? Oh well :)
-- regards, Kalle Sommer Nielsen kalle@php.net

Joe Watkins

9 years ago
Afternoon internals, This is not a new subject for discussion, it has been discussed over and over, and I'm quite sure that many people had formed an opinion on 50%+1 votes before the RFC was posted. One week to allow new points to be raised seems fair enough to me. I didn't say there would be a shorter voting period, and I'm quite happy to leave the vote open for two weeks to allow votes to come in. This isn't a case where opinion is likely to change the content of the RFC: I'm not looking to change a bunch of rules, or implement a very complicated feature. We are only looking to answer the question "should we abolish 50%+1 votes" ... For such a simple question, 3 weeks in total should be long enough. Cheers Joe On Sat, Nov 19, 2016 at 11:37 AM, Kalle Sommer Nielsen <kalle@php.net> wrote:

Lester Caine

9 years ago
On 19/11/16 12:10, Joe Watkins wrote:
> For such a simple question, 3 weeks in total should be long enough.
Is this simply ... Every element of a vote has to achieve 2/3rds? While there are many cases where a simple yes/no question can eventually be agreed on, and I would prefer that some of the 50/50 decisions had a much greater consensus, areas where there is no clean consensus will not be solved 'simply' by moving the goal posts? The main problem is simply that there is not a common consensus on just how PHP should develop, and things like 'who can vote' and getting a sensible number of people to agree on something is just as important. The recent RFC on 'Debugging PDO Prepared Statement' is a good example of where people who may be affected have no vote, but people who could properly assess the now approved patch don't have the time or incentive to do so. A number of current RFC's have overlapping elements where a consensus on the base approach may be of more use than patching individual parts in isolation. A vote on the 'roadmap' element with sub sections on elements which may well not be appropriate for a full 3/2rds in light of the main question.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Joe Watkins

9 years ago
Afternoon Lester,
> Is this simply ... Every element of a vote has to achieve 2/3rds?
Yes, it is. But before you rubbish that idea as ridiculous, think about what it really means. It doesn't mean that people will continue to open a 2/3 vote and then pin a list of subsidiary decisions onto the voting stage. It does mean that the author of the RFC is forced to open a vote with clear, simple options, that must be acceptable to a real majority for the motion to pass. The aim here is only to raise standards by changing our criteria for acceptance, it's one simple move. It has side effects for RFC authors, obviously, which they may first view as negative, but unarguably has a net positive effect for everyone else. Cheers Joe On Sat, Nov 19, 2016 at 12:40 PM, Lester Caine <lester@lsces.co.uk> wrote:

Nikita Popov

9 years ago
On Sat, Nov 19, 2016 at 2:03 PM, Joe Watkins <pthreads@pthreads.org> wrote:
> Afternoon Lester, > > > Is this simply ... Every element of a vote has to achieve 2/3rds? > > Yes, it is. > > But before you rubbish that idea as ridiculous, think about what it really > means. > > It doesn't mean that people will continue to open a 2/3 vote and then pin a > list of subsidiary decisions onto the voting stage. > > It does mean that the author of the RFC is forced to open a vote with > clear, simple options, that must be acceptable to a real majority for the > motion to pass. > > The aim here is only to raise standards by changing our criteria for > acceptance, it's one simple move. > > It has side effects for RFC authors, obviously, which they may first view > as negative, but unarguably has a net positive effect for everyone else. > > Cheers > Joe >
Wait ... what? I assumed that this proposal only pertained to primary RFC acceptance votes, not to secondary votes. I don't see how 2/3 majorities make sense there. You'd either skew in favor of one option, or you'd end up in a situation where an RFC is accepted, but one sub-question has not been resolved (with supermajority) towards either option. Nikita

Lester Caine

9 years ago
On 19/11/16 13:03, Joe Watkins wrote:
> But before you rubbish that idea as ridiculous, think about what it really > means.
? I'm quite happy with the idea ... all I was rubbishing is the idea that it's a 'simple' change, but you seem to have realised that now? My only problem is with the way the language is being pushed without a substantial consensus that requires the the rules get more discussion than getting back to a 'simple' novice friendly version of PHP.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Zeev Suraski

9 years ago
> -----Original Message----- > From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of Kalle > Sommer Nielsen > Sent: Thursday, November 17, 2016 8:46 PM > To: Joe Watkins <pthreads@pthreads.org> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes > > 2016-11-17 19:22 GMT+01:00 Joe Watkins <pthreads@pthreads.org>: > > Afternoon Kalle, > > > > We have to start with the assumption that everyone that votes, does so > > with good intentions. > > Ofcourse, but I just don't think it is fair that someone who made an RFC and > never contributed anything else to the project, can have an impact on the future > of PHP just because they got a wiki account or someone who got a VCS account > for a pear package they never released > 10 years ago, but still got approved. I fully respect everyone who have > contributed to PHP now and in the past for all their hard work, but I would also > like to see a line drawn. > > > I'm sympathetic to the view that active contributors should somehow > > carry more weight with their words, or vote. But, I shy away from > > actually saying that we should only listen to those people. > > I agree that we should listen to everyone, else it becomes this closed gentleman's > club it kinda used to be. Alternatively we can have a community vote, which can > be a factor to the end result ofcourse.
FWIW, the current situation when everyone that has a VCS account gets an equal vote to someone with a thousand commits to php-src was never intended. The Voting RFC talked about code contributors, and when it was discussed verbally - we agreed we'll come up with specific criteria to what that means. That never happened, and instead, the voting system was rolled out simplistically giving voting rights to anybody with a VCS account or even wiki access. In the same way, we agreed to provide leaders of OS projects and prominent Internals contributors a right to vote - and here too, we agreed (outside the scope of the RFC) that we'd come up with criteria for that, but we never did. Long story short, what ended up happening de-facto with the Voting RFC was very very different from the discussed intent. If all those 'TBDs' strike you as odd, note that before the Voting RFC, things were waaay less formal in the PHP world, and I, for one, was surprised at how quickly the Voting RFC (as well as other RFCs) as well as the newly-created status-quo that followed it became somewhat of a constitution or a bible. If you take a look at it (wiki.php.net/rfc/voting), even with a quick glance it's clear it was basically a pretty much first draft, that miraculously became unanimously approved despite lacking clear definitions and depth, and containing many flaws. I think it's much more difficult to fix it today, but I still think it's worth it. E.g., regarding the Community voice, we could perhaps provide FIG reps with voting rights, and practically say they represent the community at large - instead of the vague and inactionable language we have there today. We didn't have that option back in 2011. We now also have github, where we can easily check the level of contribution of each VCS holder, and perhaps come up with a certain bar on what constitutes enough contribution for a vote. Those are of course just ideas, perhaps we can come up with better ones. Ultimately, who gets to vote should be better defined; Pass criteria should be better defined (in the neighborhood of what Joe's doing) along with different types of votes; And we should also clarify how these rules can be amended. Ultimately, all of these are at least somewhat inter-connected. Zeev

Joe Watkins

9 years ago
Afternoon Zeev, I am not sure how much of the voting RFC I want to reform right now. I am responding to specific problems that seem to be best fixed just by raising the acceptance criteria. I do realize that these issues are difficult to tease apart however, so intend to at least try to suggest reformations for more than one section of the voting RFC. Maybe it is time to have some of these conversations again. We do need to decide between us what is a legitimate contributor and what is not, in addition to who has a legitimate stake (such a FIG reps) ... All of us probably have ideas about that, but there isn't any consensus, so it's hard to suggest a change in this area. If a clear consensus emerged from discussion back then, it is reasonable to assume a clear consensus would emerge today, even if it changed. When you say that the voting RFC was rushed, this is news to me. Perhaps you can understand it being treated as a bible if you consider that we don't remember the bad old days, and these are the only rules we know how to play by. When new contributors come along, they don't have the benefit brought by the historical knowledge of PHP, they have to read the words in these RFC's and take them as ... gospel. I'm pleased to hear more ideas whatever. Cheers Joe On Sun, Nov 20, 2016 at 1:27 PM, Zeev Suraski <zeev@zend.com> wrote:

Zeev Suraski

9 years ago
From: Joe Watkins [mailto:pthreads@pthreads.org] Sent: Sunday, November 20, 2016 3:43 PM To: Zeev Suraski <zeev@zend.com> Cc: Kalle Sommer Nielsen <kalle@php.net>; PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes
>Afternoon Zeev, >I am not sure how much of the voting RFC I want to reform right now. I am responding to specific problems >that seem to be best fixed just by raising the acceptance criteria. I do realize that these issues are difficult to >tease apart however, so intend to at least try to suggest reformations for more than one section of the >voting RFC.
Yes, I can relate to not wanting to tackle more than one issue at a given time. I think that depending on the proposal, it may be reasonable to tackle a change in what requires a super majority independently of other issues, without radically changing the current situation of how things work. My bigger concern is that conceptually, the way things work currently is very far from the original intent of the Voting RFC. I'm at least am not aware of any other large open source project out there that has something that's even remotely close to what we evolved into in the PHP project. The vast majority of community-based open source projects are various forms of meritocracy, where your ability to influence the direction correlates in some fashion with your level of contribution. In PHP the barrier to influence is almost not there. There are several ways to tackle this - one is one I brought up a while ago, that effectively raises the acceptance bar from 2/3 to 85-90% - given that the vast majority of proposals that passed, didn't only pass with ~2/3 of the votes, but with something much close to consensus (reminder - see the analysis and proposals in www.mail-archive.com/internals@lists.php.net/msg82852.html). A different way may be changing the (de-facto) rules on who gets to vote. Or perhaps a combination of both.
>Maybe it is time to have some of these conversations again.
I think it is. As draining as it may be, I think we owe it to ourselves and PHP to try and tackle some of the deficiencies of the rushed Voting RFC, before it's even later than it already is...
>When you say that the voting RFC was rushed, this is news to me.
In my opinion it was rushed. By the time we started working on it, we had about 13 years of working in a certain way, which obviously evolved over time, but was never ever even remotely similar to what's described in the Voting RFC. And then, over the course of less than a month, we had a piece of text that a bunch of people agreed on (with some major reservations), that was as hermetic as a thing slice of Swiss cheese; A completely different way of working quickly evolved, somewhat based on a very broadening interpretation of that text - and that new way of working became set in stone. Looking back at my email archive, I think we did recognize that there were some tricky parts in this RFC, and that it would be very difficult to change: "Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition." ... and yet, there was a very strong bias to get *something* going, so my barely-first-draft on dealing with some of these topics became set in stone, with very few updates and little scrutiny from anybody. I think that there were large groups of people who believed (based on the discussion on the list) that we'd still first strive for near-consensus before even bringing up RFCs for voting, which as we all know - turned out to be very far from what happened in reality. Others thought that it wouldn't be a big deal to amend and improve this as we go along - which also turned out to be disconnected from reality as not a single change was made in the last 5 years (except the de-facto changes, like who gets to vote). I think the feeling back then was that "anything is better than nothing", and perhaps it was - but it certainly pushed us to move ahead with a half-baked solution. This RFC went to a vote two weeks after I made these statements and made my edits, with virtually no further discussion on internals during these two weeks, and was approved 6 days later. Yes, I'd call it rushed.
> Perhaps you can understand it being treated as a bible if you consider that we don't remember the bad old days, and these are the only rules we know how to play by.
Oh I certainly do. As you can see in my quote, I expected it to become that way. What I didn't expect us to do is ratify it so quickly, when it was only slightly better baked than when I made that statement... That's the same reason I was worried about other non-technical proposals that were raised over the years - I just don't think we're very good at this law-making stuff. Zeev

Nikita Popov

9 years ago
On Thu, Nov 17, 2016 at 6:18 PM, Joe Watkins <pthreads@pthreads.org> wrote:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful. > > To what degree, I am not sure. > > I raise for discussion the topic of abolishing 50%+1 votes, and requiring > all changes regardless of their nature to pass by a super majority of > 2/3+1. > > Please read the (brief) RFC and raise objections here. > > There will be a one week discussion period for this RFC. > > Cheers > Joe >
A technical note: The existing supermajority requirement is >= 2/3, not >= 2/3+1. I think that should stay the same. Apart from that, I totally agree that everything should take a 2/3 majority. It simplifies the rules and avoids the common and very pointless discussion about what exactly constitutes a "language change". I have the vague impression that this issue has come up on pretty much every major RFC (like phpng -- Is it really a language change if it's just internals? Similar for int size changes. Similar for PHP 6 vs 7, etc.) Nikita

Joe Watkins

9 years ago
Afternoon Nikita, My mistake, changing that ... Cheers Joe On Thu, Nov 17, 2016 at 6:12 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

Niklas Keller

9 years ago
2016-11-17 18:18 GMT+01:00 Joe Watkins <pthreads@pthreads.org>:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful. > > To what degree, I am not sure. > > I raise for discussion the topic of abolishing 50%+1 votes, and requiring > all changes regardless of their nature to pass by a super majority of > 2/3+1. > > Please read the (brief) RFC and raise objections here. > > There will be a one week discussion period for this RFC. > > Cheers > Joe >
What's the reason for 2/3+1 instead of 2/3? Currently we have 50%+1 or 2/3, but not 2/3+1 as 2/3 is already a majority. Regards, Niklas

Joe Watkins

9 years ago
Afternoon Niklas, I made an off-by-one error in an RFC. Thanks for captioning my pain. Cheers Joe On Thu, Nov 17, 2016 at 6:43 PM, Niklas Keller <me@kelunik.com> wrote:

Marcio Almada

9 years ago
2016-11-17 13:18 GMT-04:00 Joe Watkins <pthreads@pthreads.org>:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful. > > To what degree, I am not sure. > > I raise for discussion the topic of abolishing 50%+1 votes, and requiring > all changes regardless of their nature to pass by a super majority of > 2/3+1. > > Please read the (brief) RFC and raise objections here. > > There will be a one week discussion period for this RFC. > > Cheers > Joe > >
Hi Joe, I fully support the change to always require super majority on all votings. Sometimes RFCs don't contain a language change (by the criteria defined on our wiki) but can contain BC breaks. I used to believe the RFC authors would have the sensibility to always raise the bar higher in these cases, but it's much better to change the system to enforce super majority IMMO. About the requests to have 75%+1 votes, I believe raising the bar too high could be damaging when entering a new major release in the future. But perhaps RFC authors that stand for 75%+1 voting could propose RFCs with that ratio instead of 2/3+1 if they think it's necessary. PS: I wonder if the voting to change the process to always require 2/3+1 will be a 50%+1 poll? :P Ty, Márcio Almada.

Levi Morrison

9 years ago
On Thu, Nov 17, 2016 at 10:18 AM, Joe Watkins <pthreads@pthreads.org> wrote:
> Afternoon internals, > > This has been discussed before in various RFC threads, there does seem to > be some consensus that 50%+1 votes could be harmful. > > To what degree, I am not sure. > > I raise for discussion the topic of abolishing 50%+1 votes, and requiring > all changes regardless of their nature to pass by a super majority of > 2/3+1. > > Please read the (brief) RFC and raise objections here. > > There will be a one week discussion period for this RFC. > > Cheers > Joe
As I have voiced in the past I completely agree with moving to >= 2/3. I would also consider supporting >= 3/4. I believe that PHP is at a point in its lifetime that new features or changes should not be considered lightly, which is why I would consider supporting something more strict than 2/3.

Pierre Joye

9 years ago
Good afternoon, On Nov 18, 2016 12:18 AM, "Joe Watkins" <pthreads@pthreads.org> wrote:
> > There will be a one week discussion period for this RFC.
Sorry but the minimum discussion period for RFC is two weeks. No exception. I will reply later for the feedback on the RFC :) Cheers Pierre

Joe Watkins

9 years ago
Morning Pierre, That's not what the rules say. There will be a one week discussion period. Cheers Joe On 19 Nov 2016 2:20 a.m., "Pierre Joye" <pierre.php@gmail.com> wrote:

Levi Morrison

9 years ago
On Fri, Nov 18, 2016 at 9:11 PM, Joe Watkins <pthreads@pthreads.org> wrote:
> Morning Pierre, > > That's not what the rules say. > > There will be a one week discussion period. > > Cheers > Joe > > On 19 Nov 2016 2:20 a.m., "Pierre Joye" <pierre.php@gmail.com> wrote: > >> Good afternoon, >> >> On Nov 18, 2016 12:18 AM, "Joe Watkins" <pthreads@pthreads.org> wrote: >> >> > >> > There will be a one week discussion period for this RFC. >> >> Sorry but the minimum discussion period for RFC is two weeks. No exception. >> >> I will reply later for the feedback on the RFC :) >> >> Cheers >> Pierre >>
See https://wiki.php.net/rfc/howto; it does say two weeks minimum in step 6. If you know of anywhere it says one week please let me know.

Pierre Joye

9 years ago
On Nov 19, 2016 11:11 AM, "Joe Watkins" <pthreads@pthreads.org> wrote:
> > Morning Pierre, > > That's not what the rules say. > > There will be a one week discussion period.
Sorry but no. https://wiki.php.net/rfc/howto

Joe Watkins

9 years ago
Morning Pierre, Sorry, but yes. http://wiki.php.net/rfc/voting
> There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required. Other RFCs might use a smaller timeframe, but it should be at least a week. Cheers Joe On Sat, Nov 19, 2016 at 4:28 AM, Pierre Joye <pierre.php@gmail.com> wrote:

Pierre Joye

9 years ago
On Nov 19, 2016 11:34 AM, "Joe Watkins" <pthreads@pthreads.org> wrote:
> > Morning Pierre, > > Sorry, but yes. > > http://wiki.php.net/rfc/voting > > > There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required. Other RFCs might use a smaller timeframe, but it should be at least a week. Seriously Joe, this is ridiculous. You are forcing a shorter period of time for something that does affect PHP at a whole. Be fair and let anyone raises their feedback.

Peter Cowburn

9 years ago
On 19 November 2016 at 10:45, Pierre Joye <pierre.php@gmail.com> wrote:
> On Nov 19, 2016 11:34 AM, "Joe Watkins" <pthreads@pthreads.org> wrote: > > > > Morning Pierre, > > > > Sorry, but yes. > > > > http://wiki.php.net/rfc/voting > > > > > There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is required. > Other RFCs might use a smaller timeframe, but it should be at least a week. > > Seriously Joe, this is ridiculous. You are forcing a shorter period of time > for something that does affect PHP at a whole. > > Be fair and let anyone raises their feedback. >
Ignoring whether this RFC "touches the language" (phrasing I've always taken issue with) and as such *requires* a two-week discussion period. I think this particular RFC should be given two weeks, or longer, for everyone to have their say. Given that it is Thanksgiving next week, for purely practical reasons, I think it necessitates a *longer* discussion period (than one week) as interested parties may simply not be around at all. For a process-related RFC such as this, forcing a one-week discussion period when a large number of folks mightn't even be looking at the list, reads as irresponsible, to me at least. Regards, Peter (who apologises in advance for poking the bear)

Yasuo Ohgaki

9 years ago
Hi all, On Sat, Nov 19, 2016 at 7:45 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Nov 19, 2016 11:34 AM, "Joe Watkins" <pthreads@pthreads.org> wrote: >> >> Morning Pierre, >> >> Sorry, but yes. >> >> http://wiki.php.net/rfc/voting >> >> > There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is required. > Other RFCs might use a smaller timeframe, but it should be at least a week. > > Seriously Joe, this is ridiculous. You are forcing a shorter period of time > for something that does affect PHP at a whole. > > Be fair and let anyone raises their feedback.
I don't look internal list weeks sometimes. 2 weeks is reasonable period for me, not too long nor too short. I guess a week is too short during holiday season for most people. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Stas Malyshev

9 years ago
Hi!
> Sorry, but yes. > > http://wiki.php.net/rfc/voting > >> There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is required. > Other RFCs might use a smaller timeframe, but it should be at least a week.
I must say I don't understand Joe's position here. Where's the fire? Why can't we afford two-week or three-week discussion? How does it make sense to make a huge change in voting rules after tiniest amount of discussion possible? If anything, we should take as long as it requires for such things, not try to rush it through. I think minimal discussion time is way unadequate for such thing. It's not adding optional argument for an obscure PDO function, it's changing the rules for the whole project. I see absolutely no reason not to let the discussion unfold and be as long as it needs to be.
-- Stas Malyshev smalyshev@gmail.com

Zeev Suraski

9 years ago
> -----Original Message----- > From: Joe Watkins [mailto:pthreads@pthreads.org] > Sent: Saturday, November 19, 2016 6:11 AM > To: Pierre Joye <pierre.php@gmail.com> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes > > Morning Pierre, > > That's not what the rules say. > > There will be a one week discussion period. > > Cheers
Joe, Changing the rules should at the very least be as long as the longest discussion period and the highest majority defined in the Voting RFC, and arguably, longer (which I think it should be here). It's really not sensible otherwise - a group with a simple majority could change the voting rules to require only a simple majority for everything, and pass whatever RFC it wants with a simple majority. Changing the rules is bigger than any single language-level decision, as it effects all future decisions going forward. The original Voting RFC was rushed, and we're all still suffering from the consequences many years later. There's really no need to do it again. Regarding the substance of the RFC, I think Andrea and perhaps others touched on an issue - a 2/3 majority doesn't make sense for situations when we need to pick an option, when none of the options has any inherent bias towards them. When we deal with features, we did define a bias-for-status-quo, which means a 2/3 majority is needed to change it. I agree that the definition of 'features that change the language' is a poorly phrased one (file under 'rushed'), and that other types of features should also be passed in a 2/3 vote. However, there are decisions which really boil down to nothing more than an opinion, where even if the status quo exists or is implied - there's no inherent difference between the choices. For example, the decision on how to version PHPNG that we faced about a year and a half ago. Should '7' have required a 2/3 majority, because '6' is the perceived default? I would disagree. It's a simple matter of opinion, doesn't change the language in any way, and 6 isn't more 'status quo' than 7 in any way that 7 is more than 6. Also, other administrative decisions, such as delaying a release for whatever reasons (like we did for the inclusion of OPcache, IIRC) - should also be a simple majority. I think the test that Michael brought up - "does it have any backwards compatibility or forwards compatibility implications?", is probably the right one to have. In other words - if it breaks BC, it requires a supermajority. If it adds something that, if removed/changed in the future, would introduce BC - it requires supermajority. Otherwise - it's a simple majority (>50%, or even just the option that got the most votes in case of a 3-way or 4-way vote). On top of that, to clarify, the rules themselves should definitely require supermajority to change (arguably higher than the current 2/3 we have; the original Voting RFC was passed in consensus). Zeev

Joe Watkins

9 years ago
Afternoon Zeev, It first seemed like a very simple question to abolish 50%+1 votes, it quickly become apparent that this is not viable in any sense. Maybe I should have spotted that it wasn't sensible, maybe Pierre did and thought I was crazy, maybe Pierre thought I had spotted it but didn't care ... I was just late to realise that what I was suggesting doesn't make sense :) I did later reply that I intend to properly review mine and other's ideas, and will be back with suggestions. Thanks for your input. Cheers Joe On Sun, Nov 20, 2016 at 1:01 PM, Zeev Suraski <zeev@zend.com> wrote:

Michael Morris

9 years ago
Otherwise - it's a simple majority (>50%, or even just the option that got
> the most votes in case of a 3-way or 4-way vote). >
There are better options for choices of 3 or more than the most votes system and I strongly recommend that they be used. Allow me to present an example. Suppose we needed to include new functionality in PHP, and there where three libraries available to provide it. A is the oldest and most mature but hasn't been maintained in awhile. B is a less stable fork but has more active maintenance. A & B have the same API. C is the newest cutting edge version, but has a different API. A vote is held. 32% for A, 31% B and 37% for C. C wins in this scenario because the majority was split across the two similar choices A & B. If ranked choice ballots were used in this scenario B would be eliminated on the first round and the second choices of those ballots would be examined with an end result of 58% for A, 42% for C, meaning most of the supporters of B would settle for A but didn't really like C. A lot of the bad blood in American politics can be directly linked to this problem - splitting a majority in 3 or more way races. Political parties arose specifically to prevent this splitting, but its a case that the cure is worse than the disease. I don't think PHP is in any danger of devolving into this sort of acrimony, but it's still worth avoiding the problem entirely with ranked choice balloting where appropriate.