[EM] New negotiation ranking software for legislators, councilors, parliaments, etc.

[Richard]

TLDR summary:  Portland's recent city-council STV election revealed that 
electing councilors using PR (proportional representation) is just the 
first step in fully representing the full spectrum of voters.  We also 
need to create a voting-based "negotiation ranking" platform that allows 
all the councilors to better communicate with each other to design 
better laws and taxes.  Those wiser laws and taxes will increase the 
city's economic prosperity.  This same development is needed in state 
legislatures and parliaments, and eventually in US Congress.  Without 
this broader collaboration, a slim majority of legislators controls the 
legislature, and the wisdom in the opposing PR-elected legislators is 
dismissed.  This dismissal of wisdom leads the city, state, or nation 
into lower levels of economic prosperity.  New software that does the 
vote counting at the core of this "negotiation ranking" process is now 
available on GitHub in the CPSolver account (link: 
votefair.org/negotiate), and its algorithm is described in this post.



Why we need a "negotiation ranking" software algorithm:

Portland's use of STV (the single transferable vote) to elect a new city 
council worked beautifully.  The 12 elected councilors are nicely 
representative of a full range of Portland voters.

Unfortunately the voting process used within the city council is not 
working well.  Too often decisions are made with support from just 7 
councilors, against opposition from the other 5 councilors.  In these 
cases about 40 percent of Portland voters are represented by the 
opposing councilors, but those councilors are dismissed.  This dismissal 
defeats the underlying goal of PR, which is to represent as many voters 
as possible.

Initially I believed the Portland councilors needed to increase 
communication with one another outside of official public meetings. 
Then I learned there's a rule that prohibits private conversations among 
more than 5 councilors.  In hindsight this rule wisely prevents the 
formation of a "ruling coalition" that makes its decisions in private 
meetings.

Years ago I created a "negotiation ranking tool" at NegotiationTool.com 
that I initially designed to handle voting among MPs (members of 
parliament).  Earlier this year I realized a better version of it might 
be useful as the foundation of a communication platform that 
(eventually) could be used by elected legislators, such as the 12 
members of the Portland city council.

That older software tool had some significant flaws, so I've written an 
entirely new "negotiation ranking tool" that replaces the old one.  Now 
I'm announcing this new second version.

I'm still testing and refining some parts of the code, so it's not yet 
ready for use in legislatures or city councils.  Yet it's working well 
enough to be used as a starting point for developing even better 
algorithms.  Also, at my age, 75, I may not be around long enough to 
refine it as much as I would like.

To clarify, this negotiation software only focuses on the vote-counting 
algorithm.  It does not include a "front-end" "web app" through which 
participants can add proposals and vote.

Already at LiquidFeedback.com there is a communication platform, built 
by a German business, that demonstrates the user-interface portion of 
such a communication platform.

As you might recognize, this path overlaps with the path toward "liquid 
democracy" that's popular among some election-method advocates.  In that 
case, citizen voters and "delegates" will be the "participants" doing 
the voting.

To avoid violating Portland's private-meeting rule for city-council 
members, the proposals and the voting data would need to be available to 
the public, either openly shared or available after filing a records 
request.

It might be tempting to simply require a higher supporting-vote 
threshold, such as a two-thirds majority.  That path overlooks the fact 
that sometimes decisions really should be passed with just a slim majority.

The biggest advantage of improving communication among all PR-elected 
representatives is that wiser legislative decisions yield higher levels 
of economic prosperity for the city, state, or nation.  Expressed in 
reverse, authoritarian governments and corrupt governments increase 
economic suffering for most people (while enriching relatively few people).

If anyone isn't familiar with why higher levels of democracy lead to 
higher levels of economic prosperity, some key reasons are explained at: 
VoteFair.org/econ ( 
https://htmlpreview.github.io/?https://github.com/cpsolver/websites/blob/master/VoteFairDotOrg/taker_tactics.html 
)

Now that you understand the purpose of "negotiation ranking" software, 
here's how to use it, and how the algorithm works ....



Getting the open-source "negotiation ranking" software:

Here's a link to the README file that describes further details about 
version 2 of my "negotiation ranking" software, including how it can be 
used, and how it works.

   votefair.org/negotiate

Here's the link to the software itself.  It's a single file named 
"negotiation_tool.cpp".  The code is written in the C language, except 
for some input/output code written in C++.  Any C++ compiler should 
compile it, without needing any other software.

   votefair.org/negotiation_code

A sample scenario I've created for testing this software is in the file 
named: "input_cabinet_ministers.txt"  In this scenario, MPs (members of 
parliament) choose cabinet ministers, including the prime minister.  The 
algorithm does not have access to any information about political-party 
affiliations, yet the "accepted" cabinet ministers represent multiple 
political parties.  As far as I know, existing election methods do not 
handle this scenario.  FYI, normally this negotiation process is done in 
private by the "leaders" of the ruling coalition.

In case the above short links break, here's the URL to the GitHub folder 
that contains the files:

https://github.com/cpsolver/VoteFair-Negotiation-Tool/tree/master



Algorithm highlights:

Here are explanations of some of the algorithm highlights so you don't 
need to read the long README file:

* The algorithm uses "satisfaction counts," which are derived from 
"pairwise support counts minus pairwise opposition counts."  These 
satisfaction counts can be calculated on a per-participant basis or a 
per-proposal basis.

* On a single ballot, the "pairwise support count" is the number of 
proposals that are ranked lower than the proposal being considered.  The 
"pairwise opposition count" is the number of proposals that are ranked 
higher than the proposal being considered.

* Very importantly, this support and opposition counting ignores some 
proposals based on other considerations.

* During pairwise support and opposition counting, "pairwise losing 
proposals" are eliminated, at least temporarily, whenever possible.  A 
pairwise losing proposal is a proposal that would lose every one-on-one 
contest against every other remaining proposal.

* Here's a graphic that shows how the pairwise support and opposition 
counts are counted on a single ballot:

   https://votefair.org/pairwise_support_opposition.png

* The satisfaction counts are normalized and then inverted to become 
ballot weights during the next calculation steps.  This 
normalize-and-invert step reduces influence for participants who are 
well-represented by the proposals already "accepted."  Conversely, it 
gives full ballot influence to participants who are not yet 
well-represented.

* When a proposal is identified as next-most popular (among remaining 
proposals, based on possibly adjusted ballot weights), a "disparity gap" 
is calculated to determine whether this next-most-popular proposal 
should be accepted.

* A larger disparity gap, which indicates a significant number of 
participants are not yet sufficiently well-represented, is needed for a 
proposal to be accepted.  A small disparity gap indicates the 
participants being considered are sufficiently well-represented, so the 
considered proposal is not accepted.

* A group of participants being considered for increased representation 
is regarded as an opposition "coalition."  These coalitions exist only 
temporarily.  The participants are identified based on the sort order of 
all the satisfaction counts.

* The disparity gap is calculated as the difference between the average 
satisfaction count of the opposition coalition and the average 
satisfaction count of the coalition they oppose.

* Incompatibility information also needs to be supplied.  This info can 
be added when the list of accepted proposals includes two incompatible 
proposals.  Then the software is run again and only one of the two 
incompatible proposals is listed among the accepted proposals.

* When a proposal is considered for acceptance because of being the most 
popular proposal (under current ballot weights), the popularity 
calculation is repeated among just that proposal and the proposals that 
are incompatible with it.  This step defends against tactical voting in 
which a participant otherwise could change a pairwise support count or 
opposition count by exaggerating the ranking of an unrelated unpopular 
proposal.

* Sincere attempts to clarify a participant's priorities can affect the 
results.  However, attempts to exaggerate any rating/ranking numbers to 
gain extra influence will likely either fail or backfire.

* The rating/ranking numbers are not ratings, and they are not rankings.

* Internally the rating/ranking numbers are used to identify the 
sequence in which the proposals can be ranked as first choice, second 
choice, etc.  Changing the size of a gap between two numbers does not 
affect the sequence, so it cannot affect the results.

* The calculations use "pairwise counting."  This means the numbers 
assigned to two proposals are compared to determine which proposal is 
ranked higher than the other.  As a result, the rating/ranking numbers 
from one participant are never compared to the numbers from any other 
participant.  This flexibility allows different participants to 
interpret their numbers without concern about how other participants 
interpret their numbers.

* Multiple proposals can be given the same rating/ranking number.

* Positive rating/ranking numbers up to 100 indicate liking, and 
negative numbers down to minus 100 (-100) indicate disliking.

* The number zero is given to each new proposal.  It indicates a neutral 
preference, neither liked nor disliked.

* Most participants will begin by putting the proposals into "like" and 
"dislike" categories, and default numbers (such as 50 and -50) are 
assigned automatically by the (not-included) interactive software.

* As the negotiation process continues, some participants will sort the 
proposals into a larger number of rating/ranking categories.  For 
example the categories might include "strongly like" and "weakly 
dislike," for which the interactive software might assign numbers such 
as 70 and -30.

* As the negotiation process converges on a collection of proposals that 
are widely supported, each participant is expected to adjust their 
rating/ranking numbers.  Their goal is to block disliked proposals from 
being accepted, and to push liked proposals into becoming accepted.

* An important part of the negotiation process is to offer new proposals 
that might be more acceptable to other participants.  Ideally these new 
proposals will be based on insights about hidden opportunities for two 
"sides" to both achieve their highest priorities.

* In many cases a greedy proposal can be split up into smaller proposals 
so the most popular components become accepted, and the less-popular 
components are replaced by new more-popular (and less-greedy) proposals.

* The internal popularity calculations use "Instant Pairwise 
Elimination" (IPE).  This election method eliminates pairwise losing 
proposals when they occur, and otherwise eliminates the proposal with 
the "largest pairwise opposition count" or the "smallest pairwise 
support count."  Although this method does not always choose the 
Condorcet winner, otherwise this method has failure rates that are 
similar to the Condorcet-Kemeny method, as shown at: 
https://votefair.org/clone_iia_success_rates.png

* If needed, the proposals can be nominations for specific candidates to 
get elected to specific offices, the candidates can have political-party 
affiliations, and the participants can have political-party preferences. 
  In these cases the software is not aware of these affiliations or 
preferences.  Yet the accepted proposals will yield proportional results 
similar to what a non-partisan PR method such as STV would yield, but 
without the mathematical limitations of STV.


In case the overall concept is not yet clear, here's a link to a graphic 
that attempts to summarize the general ideas behind this software:

   https://votefair.org/legislative_negotiation.png

The README file, and the many comments in the code file, explain lots of 
other details.

To repeat, my goal is to help accelerate the process of developing 
voting systems that go beyond just improving elections.  As Portland's 
recent STV city-council election has revealed, getting PR into a 
legislature is just the first step.  Next we need to create tools that 
facilitate cooperation among the legislators, councilors, and MPs who 
get elected using PR methods.  Ignoring lots of these wisely elected 
representatives gives us a tyranny of the majority, a rejection of wise 
leadership, and declining economic prosperity.  We already have too much 
of that.

If you have any questions, just ask.

Richard Fobes
the VoteFair guy