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