On Sunday, April 6, a new version of LiquidFeedback Core (version 3.0.1) was released, which applied changes to the vote counting process if default settings are selected.[PSG] This article shall give information about the background and reasoning regarding these changes in LiquidFeedback.
While it is most “democratic” to treat all voting options in a ballot equally, it is often desired to treat the status quo in a special way.[PLF, p.101]
Consider the following example, which is also given in our book [PLF, p.102]:
We have 3 options: A, B, and the status quo (SQ).
49% of the voters prefer B to A to SQ.
21% of the voters prefer SQ to B to A.
19% of the voters prefer SQ to A to B.
11% of the voters prefer A to SQ to B.
When compared to SQ, then A has a majority:
60% of the voters prefer A to SQ.
When compared to SQ, then B has no majority:
51% of the voters prefer SQ to B.
But there is also a majority which prefers B to A:
70% of the voters prefer B to A.
If we treat all options equally and use the Schulze method (Schwartz Sequential Dropping) to determine a winner, then B is selected as winner, as the defeat of SQ over B is weakest (51%) and thus eliminated. (The Schulze ranking is: B > A > SQ.)
Such voting rule, where B wins, may be considered counterintuitive though, because only a minority (49%) likes to replace the status quo with B.
Markus Schulze proposes in his draft “A New Monotonic, Clone-Independent, Reversal Symmetric, and Condorcet-Consistent Single-Winner Election Method” [Schulze, p.65-66], May 19, 2014 that the candidate with the best Schulze rank wins which (a) gains a majority in direct comparison with the status quo and (b) has a better Schulze rank than the status quo. If no such candidate exists, then the status quo wins.
His approach, however, has the following drawback: it may select a candidate as winner which would be replaced by another candidate if the ballot was repeated (and all candidates kept their preferences).[PLF, p.102] Thus, requiring a candidate to have a direct majority when compared to the status quo may yield “unstable” results. Such an unstable result won't cycle (as the current status quo is never replaced with a candidate having a worse Schulze rank), but repeating the ballot with the same voters' preferences may still yield another result, thus changing the status quo multiple times before the result gets stable.
In the above example, applying Markus Schulze's proposal results in candidate A being the winner, because it has the best Schulze rank amongst those candidates which have gained a majority in comparison to the status quo. After selecting candidate A as winner, repeating the ballot will cause B to be winner, because if A is the new status quo, then B has a majority in direct comparison to the status quo (and a better Schulze rank than A).
In some contexts, changes of the status quo shall be minimized as, for example, major efforts have to be taken to implement an approved motion. In these cases it is undesired to use a voting system that may create “unstable results” as explained above.
For this reason, LiquidFeedback (Core version 2.x and 3.0.0) provided configuration options to disallow such results. One of those configuration options was named “prohibit reverse beat-paths” and this option forbids a candidate to win if there is a beat-path (including ties) to the status quo.[PLF, p.103] In the example above, this causes candidate A to be uneligible as winner, resulting in the status quo as winner (which is a “stable” result).
The feature of prohibiting reverse beat-paths was also intended to be used in combination with supermajority requirements (e.g. a 2/3-majority requirement) to avoid a cycling status quo due to slightly changing majorities. Consider the second example that we also gave in our book [PLF, p.105]:
We have 3 options: A, B, and the status quo (SQ), and a 2/3-majority is required to change the status quo.
33% of the voters prefer B to A to SQ.
33% of the voters prefer SQ to B to A.
34% of the voters prefer A to SQ to B.
If we simply require a 2/3-majority in a pairwise comparison with the current status quo, then, using the Schulze method, candidate A wins. Subsequent repetitions of the ballot (assuming honest voter behavior) would not change the situation. However, just 1% of the voters with volatile behavior could cause a cycle of the status quo in subsequent repetitions of the ballot, despite the fact that a 2/3-majority is required.
Also here, prohibiting reverse beat-paths from the winner to the status quo would have stabilized the situation by enforcing the current status quo to be winner (since a cycle exists).
When introducing the feature of prohibiting a winner with reverse beat-paths to the status quo, we were unfortunately not aware that McKelvey and Bell have shown that, under certain assumptions, the probability of beat-paths from any alternative to any other alternative (including the status quo) tends toward 100%.[McKelvey][Bell] These findings have also been referred to as the “chaos theorems”.[Schofield, p.196] The consequences for LiquidFeedback Core version 2.x or 3.0.0, if used with previous default settings, is that any group able to reach the second quorum (initiative quorum) in an issue might (theoretically) be able to give a serious advantage to the status quo by placing initiatives strategically, particularly also in case of honest voting behavior of the participants.
Disallowing a beat-path from a potential winner to the status quo does not just protect the status quo, but under certain circumstances it enables a minority to enforce the status quo as winner. Therefore, we must conclude that due to the findings of McKelvey the drawbacks of our approach outweigh the advantages. As we became aware of that, we revised the counting of the preferential voting in LiquidFeedback by marking the feature “prohibit reverse beat-paths” as experimental and disabling it by default,[PSG] causing LiquidFeedback to follow Markus Schulze's recommendations[Schulze, p.65-66] instead.
As a consequence of following Markus Schulze's recommendation here, it is possible that a candidate wins which is neither the status quo nor that candidate with the best Schulze rank. The Schulze method, however, sometimes lacks resolvability in regard of the second, third, etc. Schulze rank: the probability that the candidate gaining the second and the candidate gaining the third Schulze rank are tied doesn't tend toward zero as the number of voters increase, and adding a single ballot to a result doesn't always solve ties between candidates.[Schulze, p.38, reference to example 3]
LiquidFeedback Core until version 3.0.1 resolved ties by simply letting that initiative win that was created first in the system.[PLF, p.101] As using randomness is not an option (due to practical considerations and the necessity of verifiability), this has been a reasonable approach as long as ties are an exception. However, disabling the feature “prohibit reverse beat-paths” and thus allowing initiatives to win that do not gain the first Schulze rank but the second, third, etc. increases the chance that such ties can happen.[PLF, p.100][PLF, 2nd footnote on p.103] Therefore, initiatives that were created earlier than other initiatives would gain an unfair advantage.
For these reasons, LiquidFeedback Core 3.0.2 implements a new form of tie-breaking that has been proposed by Markus Schulze[Schulze, p.58] and which will be explained in the following article.[Tie]