I find this a very clever solution that achieves similar results with an even simpler algorithm. To clarify:
- Each candidate proposal is broken down in two independent entries. So if a candidate has a proposal structure that is 400k basic and 600k extended scope, then it’s broken down in two entries in the ballot: “Candidate A - Basic - 400k” and “Candidate A - Extended - 200k” (notice that in the extended proposal we are just putting the value of the difference from the basic)
- When considering a ballot, IF the vote ranks Basic under Extended, then we modify the ballot such that basic is ranked directly above extended. For teams building a voting UI, we will ask them to enforce that when writing the ballot, but if someone submits a “non compliant” ballot, we simply consider it as if it was changed in this way.
- The ranking of all entries (including None Below) is then calculated in a standard Copeland method.
- Once the ranking is complete, from top to bottom, we will try to fit projects in the 2 year stream, and then on the 1-year stream using the standard knapsack algorithm, stopping once budgets are exhausted or None Below is reached.
- Once we have ranked 5 projects OR if a project’s budget won’t fit in the 1 year stream we will remove any remaining budget from the 2-years and bring it to the 1-year stream.
Nick’s new proposal allows more detailed expressivity, while simplifying the current algorithm by a lot. Some of the properties that needed express rules (like downgrading a project’s extended to basic if it wouldn’t fit) now become inherent properties of the system. As far as I can tell it removes the vote splitting issue (at least in the example I provided), but we need some time to evaluate it.
It presents some UI challenges on ranking 50 different entries, but we might be able to overcome this with better interfaces.