# [RFC] Abolish 50%+1 Votes - Thread: https://externals.io/message/96960 - Original archive: https://news-web.php.net/php.internals/96960 - Started by Joe Watkins on 2016-11-17T17:18:10+00:00 - Messages: 58 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/96960.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #96960 — Joe Watkins — 2016-11-17T17:18:10+00:00 URL: https://externals.io/message/96960#96960 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 --- ## #96961 — Dennis Clarke — 2016-11-17T17:33:15+00:00 URL: https://externals.io/message/96960#96961 · In reply to: #96960 > 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 --- ## #96965 — Joe Watkins — 2016-11-17T17:37:11+00:00 URL: https://externals.io/message/96960#96965 · In reply to: #96961 Afternoon internals, https://wiki.php.net/rfc/abolish-narrow-margins Cheers Joe On Thu, Nov 17, 2016 at 5:33 PM, Dennis Clarke wrote: > > > > […] > > 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 --- ## #96962 — Joe Watkins — 2016-11-17T17:53:11+00:00 URL: https://externals.io/message/96960#96962 · In reply to: #96960 Afternoon internals, https://wiki.php.net/rfc/abolish-narrow-margins Cheers Joe > 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 --- ## #96963 — Christoph M. Becker — 2016-11-17T17:57:24+00:00 URL: https://externals.io/message/96960#96963 · In reply to: #96960 > 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 --- ## #96964 — Kalle Sommer Nielsen — 2016-11-17T17:59:15+00:00 URL: https://externals.io/message/96960#96964 · In reply to: #96960 Hi Joe 2016-11-17 18:18 GMT+01:00 Joe Watkins : > 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 --- ## #96966 — Joe Watkins — 2016-11-17T18:03:40+00:00 URL: https://externals.io/message/96960#96966 · In reply to: #96963 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 wrote: > > > > […] > > 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 --- ## #96967 — Nikita Popov — 2016-11-17T18:12:02+00:00 URL: https://externals.io/message/96960#96967 · In reply to: #96960 > 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 --- ## #96968 — Joe Watkins — 2016-11-17T18:13:02+00:00 URL: https://externals.io/message/96960#96968 · In reply to: #96967 Afternoon Nikita, My mistake, changing that ... Cheers Joe > On Thu, Nov 17, 2016 at 6:18 PM, Joe Watkins > wrote: > > > […] > > 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 --- ## #96969 — Rowan Collins — 2016-11-17T18:16:35+00:00 URL: https://externals.io/message/96960#96969 · In reply to: #96966 > 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] --- ## #96970 — Joe Watkins — 2016-11-17T18:22:09+00:00 URL: https://externals.io/message/96960#96970 · In reply to: #96964 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 > Hi Joe > > 2016-11-17 18:18 GMT+01:00 Joe Watkins : > > […] > > 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 --- ## #96971 — Joe Watkins — 2016-11-17T18:23:26+00:00 URL: https://externals.io/message/96960#96971 · In reply to: #96969 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 wrote: > > > > […] > > 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] --- ## #96972 — Niklas Keller — 2016-11-17T18:43:53+00:00 URL: https://externals.io/message/96960#96972 · In reply to: #96960 2016-11-17 18:18 GMT+01:00 Joe Watkins : > 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 --- ## #96973 — Kalle Sommer Nielsen — 2016-11-17T18:45:42+00:00 URL: https://externals.io/message/96960#96973 · In reply to: #96970 2016-11-17 19:22 GMT+01:00 Joe Watkins : > 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 --- ## #96974 — Joe Watkins — 2016-11-17T18:46:12+00:00 URL: https://externals.io/message/96960#96974 · In reply to: #96972 Afternoon Niklas, I made an off-by-one error in an RFC. Thanks for captioning my pain. Cheers Joe > 2016-11-17 18:18 GMT+01:00 Joe Watkins : > > > […] > > 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 --- ## #96975 — Andrea Faulds — 2016-11-17T18:55:34+00:00 URL: https://externals.io/message/96960#96975 · In reply to: #96969 Hi Rowan, Rowan Collins wrote: > > > […] > > 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/ --- ## #96976 — Joe Watkins — 2016-11-17T19:04:22+00:00 URL: https://externals.io/message/96960#96976 · In reply to: #96975 Afternoon Andrea, Intention was to just update the voting page, and any other related docs that might exist (maybe rfc template). Cheers Joe > Hi Rowan, > > Rowan Collins wrote: > > > […] > > 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/ --- ## #96977 — Marcio Almada — 2016-11-17T20:58:14+00:00 URL: https://externals.io/message/96960#96977 · In reply to: #96960 2016-11-17 13:18 GMT-04:00 Joe Watkins : > 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. --- ## #96978 — Andrea Faulds — 2016-11-17T21:11:59+00:00 URL: https://externals.io/message/96960#96978 · In reply to: #96976 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/ --- ## #96979 — Michael Morris — 2016-11-17T21:47:49+00:00 URL: https://externals.io/message/96960#96979 · In reply to: #96978 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. ​ --- ## #96980 — Andrea Faulds — 2016-11-17T21:59:58+00:00 URL: https://externals.io/message/96960#96980 · In reply to: #96979 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/ --- ## #96982 — Adam Baratz — 2016-11-17T22:33:49+00:00 URL: https://externals.io/message/96960#96982 · In reply to: #96969 > > The minimum number of votes is going to be the subject of another RFC, > > […] > > 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 --- ## #96983 — Michael Morris — 2016-11-17T22:51:11+00:00 URL: https://externals.io/message/96960#96983 · In reply to: #96982 > > > 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. --- ## #96984 — Levi Morrison — 2016-11-18T00:19:44+00:00 URL: https://externals.io/message/96960#96984 · In reply to: #96960 > 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. --- ## #96985 — Joe Watkins — 2016-11-18T03:49:24+00:00 URL: https://externals.io/message/96960#96985 · In reply to: #96979 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 > 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. > > ​ --- Next page: https://externals.io/message/96960.md?page=2