VoteFair-Negotiation-Tool


SOFTWARE

The file named "negotiation_tool.cpp" within this folder contains all the code needed to calculate results for VoteFair Negotiation Ranking.  The RUNNING section below explains how to run this software.  The ALGORITHM section below explains how the calculations are done.


Version 2.00

Please regard this as a beta version for experimentation purposes, and not yet ready to handle very important negotiations.  Version 1 was hosted at NegotiationTool.com but that version had significant limitations that version 2 does not have.


DESCRIPTION

What real-life situations is this tool designed to handle?

    * parliament or legislature negotiating laws, rules, taxes
    * parliament choosing cabinet ministers
    * legislative committee members writing a bill
    * city council members designing a tax change
    * political party writing a party platform
    * labor union versus management negotiating a new contract
    * proportionally filling seats on a board of directors
    * non-profit organization members resolving their differences
    * consultant and client negotiating a contract
    * buyer versus seller bargaining
    * negotiating a divorce settlement
    * electing multiple legislators from each district
    * using liquid democracy to negotiate a legal change
 

How flexible, or limited, is this negotiation tool?

* It can handle both friendly and hostile situations.

* It can handle dozens of participants, it can handle just two people, or it could be used among all members of Congress.

* It can handle hundreds of proposals if the participants, or their advisors, have time to consider all the proposals.

* Additional software must interact with the participants to collect proposals, share proposals, collect rankings for the proposals, and share the calculated list of "accepted" proposals.  This additional software is not included in the "negotiation_tool.cpp" file.

* Spreadsheets can be used to enter the rankings, but a well-designed web app would be much easier to use.



What are proposals?

* Each participant is allowed to submit multiple proposals.  A new proposal can be added at any time during the negotiation process.

* A proposal can refer, by name, to an external, longer description that specifies details.  Or the proposal can specify a simple modification of a named proposal.

* Ideally each proposal is short, just a single sentence or single paragraph.

* The participants rank the proposals as explained in the next section (below).

* Participants can refer to the proposals using any numbering system, or any naming system, but the calculation software needs a unique positive integer to identify each proposal.

* The negotiation calculations produce a recommended list of "approved" proposals that best resolve the conflicts between participants.

* The calculation software needs to know which proposals are incompatible with which other proposals.  This information is used to ensure the recommended "accepted" proposals do not conflict with each other.

* The incompatibility information can be added progressively as needed, such as when a recommended list of proposals includes some proposals that are incompatible.

* A trusted administrator can supply the incompatibility information.  Or, a few trusted participants can flag incompatible proposals when they occur in the calculated result.

* To avoid any possibility of bias, the calculation software does not have access to any text within any proposal.

* If graphics are more meaningful, each proposal can be a unique graphic (which can contain text).  In this case the ranking process can be similar to sorting photos into categories.

* When each new proposal is added to the negotiation process, it is automatically ranked at zero (0) for every participant.  The zero ranking number indicates a neutral ranking, neither liked nor disliked.



What are rankings?

* Either directly or indirectly, each proposal is assigned to a number.

* The participant can interact with user-friendly "front-end" software that uses simple category names for the rankings.  For example the two simple category names "like" and "dislike" provide a useful way to begin the ranking process.  The front-end software, which is not included in this code, converts these categories into numbers.

* As negotiation continues, the participant can use more-specific category names such as "strong like," "medium like," "weak like," "weak dislike," "medium dislike," and "strong dislike."

* As negotiation continues, some participants may directly assign numbers to indicate their ranking of the proposals.

* Positive numbers of 1 to 100 indicate the participant likes the proposal, and how strongly the participant likes it.  Negative number of minus 1 (-1) down to minus 100 (-100) indicate the participant dislikes the proposal, and how strongly the participant dislikes it.

* Zero indicates the participant has a neutral opinion about the proposal, or has not yet specified whether they like or dislike the proposal.

* The internal counting process is done in ways that defeat any attempt to change the results by limiting the use of positive ranking numbers, or by heavily using negative ranking numbers.

* Multiple proposals can be ranked at the same ranking number.

* Different front-end software can convert similar categories into different numbers.  For example, one participant who "likes" a proposal can use front-end software that internally supplies the number 50 to that proposal.  Another participant who "medium likes" the proposal can use front-end software that internally supplies the number 60.

* The numbers are only compared with numbers from the same participant!  A ranking number supplied by one participant is never compared to a ranking number supplied by a different participant.

* A participant's ranking numbers are used to determine the sequence in which the participant prefers the proposals.  Only the sequence, not the ranking numbers, are used in the calculations.

* Gaps between the ranking numbers, or a lack of gaps between rankings, do not affect the results.  This characteristic occurs because, as just explained, each ranking number is only compared to other ranking numbers from the same participant, and the numbers only determine the sequence in which the participant ranks the proposals.

* Some participants may prefer to think of the numbers as ratings rather than rankings.  This approach works if the participant remembers their numbers are never compared to the numbers used by a different participant.

* Each participant's ranking numbers are counted using pairwise counting, which is described below in the ALGORITHM section.  For now, you can think of pairwise counting as counting how many participants rank proposal 10 higher than proposal 11 and comparing that count to the count of how many participants rank proposal 11 higher than proposal 10.



How does the negotiation process work?

* Each time the negotiation tool software runs, it identifies the optimum combination of "accepted" proposals that are most strongly appreciated by the most participants.  Ideally this calculation should be done automatically whenever a ranking number changes, whenever a new proposal is added, or whenever incompatibility info changes.

* Participants view the updated list of "accepted" proposals and change their rankings of the accepted proposals.  Also they may need to change the rankings of the proposals they hope will become accepted proposals.

* If the suggested combination of proposals includes proposals that are incompatible with each other, an administrator updates the information about which proposals are incompatible with specified other proposals.  Then running the software again eliminates the incompatible proposals.

* If some participants distrust an administrator to correctly identify which proposals are incompatible with which other proposals, these incompatibilities can be voted on by participants.

* If some incompatibilities are controversial, the controversial proposals should be split up into smaller proposals with fewer incompatibilities between these newer proposals.

* Newer proposals with fewer incompatibilities should be ranked higher so that more of these simpler proposals will be among the accepted proposals.  Slowly more of these simpler proposals will replace the greedy proposals that are not widely popular.

* When negotiation progress slows down, participants should ask questions of other participants.  The questions should be sincere attempts to understand why other participants prefer different proposals.

* If the negotiation process continues with a spirit of cooperation, the results are likely to converge on a list of proposals that are reasonably well-liked by all participants, or a very large percentage of participants.

* If only slightly more than half the participants would officially vote to adopt the accepted proposals, the negotiations should continue.

* The goal should be to arrive at a list of accepted proposals that are supported by 80 percent or more of the participants.

* Full consensus (100 percent support) would be ideal, but is unlikely.  At least a few participants are likely to withhold their official vote of support until the list of accepted proposals includes an unrelated proposal of personal interest.

* This negotiation tool is a platform for communication.  However, it cannot force participants to listen to fresh perspectives from other participants, which is the basis for communication.

* As a clarification, this negotiation tool is not an artificial intelligence (AI) tool.  Instead it follows a well-defined algorithm that looks for and finds areas of agreement based on the ranking numbers supplied by the participants.

* Here's a link to a graphic that summarizes what should, and should not, be specified in a proposal, and what kinds of questions are useful:

https://votefair.org/efficient_negotiation.png

* Here's a link to a graphic that attempts to summarize the nature of this negotiation tool:

https://votefair.org/legislative_negotiation.png



RUNNING

g++ negotiation_tool.cpp -o negotiation_tool.exe

./negotiation_tool.exe < input_negotiation_tool.csv > output_negotiation_tool.json


SUPPORT AND DOCUMENTATION

A description of the calculations is below in the ALGORITHM section.

Detailed documentation is included as comments within the code.


KEYWORDS

VoteFair, negotiation, software, mediation, arbitration, liquid democracy, ranking, prioritize, priority, vote, voting, votes, voters



ALGORITHM

Here are the highlights about how the calculations are done.  This description assumes you have already read the DESCRIPTION section above.

* The ranking numbers just provide a way to identify the sequence in which each participant prefers the proposals.  Specifically, a ranking number supplied by one participant is never compared to a ranking number supplied by a different participant.

* Resolving a deep tie is the only time when the distinction between positive numbers and negative numbers can become relevant.

* A participant's ranking numbers can be regarded as that participant's ballot.

* Each participant's ballot can have full influence, or reduced influence, depending on the calculation step.  At the beginning of the calculations, and at some calculation steps, every ballot has the same full ballot weight.

* After a ballot has strongly influenced the acceptance of a proposal, the weight of that ballot is reduced.  At appropriate steps that participant's ballot is restored to the full ballot weight.

* The supplied ranking numbers are analyzed using pairwise counting.  The word "pairwise" refers to two proposals being considered as a pair of proposals.

* Pairwise counting means a proposal is either ranked higher, or ranked lower, or ranked the same as, another proposal on the same ballot.  For example a proposal assigned to ranking number 32 is counted as one proposal ranked higher than another proposal assigned to the ranking number 20.  As previously explained, the "distance" between ranking numbers is completely ignored!

* A pairwise losing proposal is a proposal that is ranked by more than half the participants as lower than every other proposal still being considered.  At every possible point, pairwise losing proposals are eliminated from consideration, either temporarily or permanently.

* To understand the pairwise losing concept using a sports metaphor, a soccer team that loses every game against every other team still in the playoffs is a pairwise losing team, and deserves to be eliminated as a possible championship team.

* A pairwise support count is the number of proposals still being considered that are ranked lower than the proposal being measured for support.  A pairwise support count can span across all ballots or be specific to a single ballot.  The pairwise support count is used to help determine which proposal is least popular among the proposals being considered.

* A pairwise opposition count is the number of proposals that are ranked higher than the proposal being measured for opposition.  As with pairwise support counts, this count can span across all ballots or be specific to a single ballot.  The pairwise opposition count is used to help determine which proposal is least popular among the proposals being considered.

* A pairwise support-minus-opposition count is the pairwise support count minus the pairwise opposition count.  This count can span across all ballots or be specific to a single ballot.

* Some calculation steps calculate a "satisfaction count."  This count is based on pairwise support-minus-opposition counts for specific proposals and a specific participant.

* Satisfaction counts measure how much satisfaction a participant has, or would have, for the acceptance of specified proposals.

* A satisfaction count considers accepted proposals compared to incompatible proposals, and considers accepted proposals compared to all non-yet-accepted proposals.

* Satisfaction calculations are used to measure the degree to which each participant might belong to an "opposition coalition" or a "dominant coalition."

* Many possible "opposition coalitions" are considered to identify a group of participants who are not well-represented by the accepted proposals.  All, or most of, the remaining participants are regarded as a possible "dominant coalition."

* Coalitions do not have names.  Each possible coalition is only identified based on the ranking numbers, and the size of each possible coalition.

* The size of an opposition coalition is a fraction such as half the participants, one third of the participants, one fourth of the participants, and so on down to about one seventh of the participants.

* The satisfaction counts are used to adjust the weight (influence amount) of each participant's ballot.  Specifically the satisfaction counts are "normalized" to give ballot weights that range from full weight to zero weight.

* Basically this ballot-weight adjustment inverts (turns upside-down) normalized satisfaction counts to become the ballot weights.  Specifically the participant with the largest satisfaction count is given a zero ballot weight, and the participant with the smallest satisfaction count is given the full ballot weight.  Typically the other participants will have ballot weights between these extremes.

* Using these adjusted ballot weights, the most popular proposal is identified.  This is the proposal that is most popular among the opposition coalition participants.

* A disparity gap is calculated to determine whether to accept a proposal that is most popular among opposition coalition participants.  This disparity gap equals the average satisfaction count of the dominant coalition participants minus the average satisfaction count of the opposition coalition participants.  If the disparity gap is sufficiently large, the proposal is accepted.  If the disparity gap is small, the proposal is not accepted.

* When the number of accepted proposals reaches the requested limit, the calculations end.  If no limit was requested, the calculations will continue until no more proposals can be accepted.

* Another limit that can be specified is the percentage of participants who dislike a proposal.  If there are any proposals that reach this percentage of "dislike" rankings, the proposal is rejected at the beginning of the calculations, before any proposal is considered for acceptance.  Neutral rankings, at rank zero, are not counted as dislikes for this purpose.

* Some participants might try to rank only one proposal with a positive number and rank all other proposals with negative numbers, in hopes of pushing that proposal to get accepted.  This tactic does not work because pairwise counting does not recognize the special zero ranking.  Also the distinction between positive numbers and negative numbers is ignored beyond the fact that negative numbers are smaller than positive numbers.

* If a participant tries to get counted in one of the many considered opposition coalitions by giving an insincere high ranking to a proposal they dislike, they risk helping get that proposal accepted.

* The way for participants to get what they want is to consider the perspective of other participants and supply proposals that clearly specify reasonable ways to achieve what they want.  Attempting to block other participants from getting what they strongly want reveals a lack of interest in the negotiation process.

* If a greedy proposal gets identified as an accepted proposal early in the negotiation process, the majority of participants can, and should, vote against officially adopting the suggested proposals.

* The input data file can include comments.  A line that begins with the number zero is ignored as if it's a comment.

* If any participant might suspect any bias based on any text (non-number) information in the input data file, comments should be omitted from the input data file.

* For additional details about the calculation steps, especially for a specific negotiation case, look at the "loginfo" messages within the output JSON file.  These messages can be turned off by including an appropriate data line in the input file.

* Here's a link to a graphic that shows how a ballot is counted to yield a single-ballot pairwise support count and a single-ballot pairwise opposition count:

https://votefair.org/pairwise_support_opposition.png



REDIRECT LINKS

VoteFair.org/negotiate links to:

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


VoteFair.org/negotiation_code links to:

    https://github.com/cpsolver/VoteFair-Negotiation-Tool/blob/master/negotiation_tool.cpp



COPYRIGHT AND LICENCE

Copyright (c) 2003-2025 Richard Fobes at www.VoteFair.org, all rights reserved.

You can redistribute and/or modify this library module under the MIT license,
a copy of which is included in the LICENSE file.

Conversions of this code into other languages are also
covered by the above license terms.