wiki:SupermajorityRequirements

NOTE: We currently discourage to use the "no_reverse_beat_path" and "no_multistage_majority" options.

Supermajority Requirements

While it is most "democratic" to treat all possible options equally, it is often desired to treat the status quo in a special way. This can help to avoid a change of the status quo by accidental majorities. It might also be desireable to enforce that a winner of a ballot always beats the status quo in direct comparison, as otherwise you might agree on a proposal, which has less votes in favor of it than votes against it but wins due to preferences in the disapproval section of a ballot.

The problem

Unfortunatly adding additional critera to the Schulze Method can cause paradox situations. Consider the following example:

We have 3 options: A, B and the status quo (SQ)

49% of voters prefer B to A to SQ
21% of voters prefer SQ to B to A
19% of voters prefer SQ to A to B
11% of voters prefer A to SQ to B

When compared to SQ, then A has a majority:
60% of voters prefer A to SQ

When compared to SQ, then B has NO majority:
51% of voters prefer SQ to B

But there is also a majority, which prefers B to A:
70% of voters prefer B to A

If we treat all options equally, then B would win, as the schulze ranking is:

  1. B
  2. A
  3. SQ

If we require an option to beat the status quo in direct comparison to be winner of the ballot, then B must not win. We might select A as winner. But doing so results in the following situation: Option A wins, but actually 70% prefer B to A. The situation can thus be considered most unstable. One possibility to fix this situation, is to neither allow A nor B to win in case of such paradox, thus resulting in SQ to win.

Approaches to a solution

Even more unfortunate is that there is no unique solution to this problem. Given the example above, every possible solution in this particular case (A, B or SQ wins) has a bad taste. The question is: What is most important? Avoid possibly "unstable" results? Require that a winner beats the status quo with a given majority?

LiquidFeedback offers a set of configuration options per policy. The following options are supported:

1st) (super)majority requirements

You may select how many approvals (absolute or relative) an initiative must get, to be attainable as winner. It is also possible to select that no majority at all is required for an a initiative to win. However also in these cases, initiatives must still get a better Schulze Ranking than the status quo in order to win. For each policy you can set two different (super)majority requirements: One which must be fulfilled by directly beating the status quo and one which may be fulfilled by indirectly beating the status quo through a beat path to the status quo.

2nd) reverse beat paths (EXPERIMENTAL)

You may decide, that a winning initiative must never be tied in a condorcet paradox (including any "weak" condorcet paradoxes with ties) with the current status quo. In combination with supermajority requirements (also with those where indirect beat paths are taken into account), this prohibts cycles of the status quo, due to slight changes of voting behaviour. A side effect of this option is to enforce that a winner always has a simple majority when compared directly to the previous status quo, without causing possible "instable" results (see below).

3rd) multistage majorities (EXPERIMENTAL)

You may select, whether an initiative should be disqualified as winner, if letting it win, could cause another intiative to win in a second ballot, which didn't have the required direct (super)majority in the first ballot. It thus disallows possibly "instable" results. If (a) there is no requirement for an initiative to directly beat the status quo or (b) the requirement to directly beat the status quo is limited to a simple majority and reverse beat paths are forbidden, then all results are stable automatically and this option has no effect on the winner of an issue.

An initiative A being better ranked than the status quo is considered to be a possibly instable result, if and only if there exists another better ranked initiative B, such that (1) more voters prefer B to A than vice versa, and (2) more voters prefer B to A than voters preferring B to the status quo or less voters prefer A to B than voters preferring the status quo to B.

Implementation / Configuration

These features have now been implemented in the mercurial repository of the LiquidFeedback core. The behaviour is configured using the following fields of a policy:

  • direct_majority_num:
    Numerator of fraction of neccessary direct majority for initiatives to be attainable as winner
  • direct_majority_den:
    Denominator of fraction of neccessary direct majority for initaitives to be attainable as winner
  • direct_majority_strict:
    If TRUE, then the direct majority must be strictly greater than "direct_majority_num"/"direct_majority_den", otherwise it may also be equal.
  • direct_majority_positive:
    Absolute number of "positive_votes" neccessary for an initiative to be attainable as winner
  • direct_majority_non_negative:
    Absolute number of sum of "positive_votes" and abstentions neccessary for an initiative to be attainable as winner
  • indirect_majority_num:
    Numerator of fraction of neccessary indirect majority (through beat path) for initiatives to be attainable as winner
  • indirect_majority_den:
    Denominator of fraction of neccessary indirect majority (through beat path) for initiatives to be attainable as winner
  • indirect_majority_strict:
    If TRUE, then the indirect majority must be strictly greater than "indirect_majority_num"/"indirect_majority_den", otherwise it may also be equal.
  • indirect_majority_positive:
    Absolute number of votes in favor of the winner neccessary in a beat path to the status quo for an initaitive to be attainable as winner
  • indirect_majority_non_negative:
    Absolute number of sum of votes in favor and abstentions in a beat path to the status quo for an initiative to be attainable as winner
  • no_reverse_beat_path:
    This option ensures both that a winning initiative is never tied in a (weak) condorcet paradox with the status quo and a winning initiative always beats the status quo directly with a simple majority.
  • no_multistage_majority:
    Setting this to TRUE, disqualifies initiatives which could cause an instable result. An instable result in this meaning is a result such that repeating the ballot with same preferences but with the winner of the first ballot as status quo would lead to a different winner in the second ballot. For a precise definition refer to the second paragraph of section "multistage majorities" above. If there are no direct majorities required for the winner, or if in direct comparison only simple majorities are required and "no_reverse_beat_path" is true, then results are always stable and this flag does not have any effect on the winner (but still affects the "eligible" flag of an "initiative").

Recommendations

To achieve the behaviour described in Markus Schulze's paper schulze1.pdf, chapter 7 (as of 2nd September 2011), select the following settings:

  • Set direct_majority_… values to whatever majority you require for an option to beat the status quo.
  • Set no_reverse_beat_path to FALSE.
  • Set no_multistage_majority to FALSE.

These settings are also the default for LiquidFeedback Core version 2.2.6, or Core version 3.0.1 and higher.

We currently discourage to use the "no_reverse_beat_path" and "no_multistage_majority" options.

Last modified 3 years ago Last modified on Aug 19, 2014, 5:10:45 PM