A generalization of STV for participatory budgeting?

[Zane Selvans]

Hi all, I've used OpaVote for our food co-op board elections in the past, but this is a more general voting system question, for use in our worker cooperative.

I am trying to coordinate a participatory budgeting process in which different participants may be responsible for allocating different amounts of the budget, across a number of different independent project tasks, each of which may require a different fixed amount of funding in order to be completed.

Intuitively, this feels like it could be done with a generalization of single transferable vote -- with STV being a special case in which all participants have the same amount of budget (vote) to allocate, and every budget category (candidate) is the same size.

Does this algorithm already exist? I've been searching and not finding anything, but it seems like someone must have already done it, and I just don't know what it's called.

The process I'm hoping we can use is to have each participant rank all the different projects (budget categories), and then allocate the (unequal) votes algorithmically, first looking at all the top priority votes, where any projects with more than enough funding are accepted (how would the votes/funding be allocated within that project? In proportion to what?) and any top priority votes that didn't end up in a funded project would then be allocated to each participant's 2nd priority project, etc. etc.

Thanks for any pointers you might have!

[Zee Spencer]

Hey Zane,

I'm really curious about this as well! I wonder if the folks at the Community Democracy Project might have a suggestion, since they do participatory democratic budgeting at the neighborhood council level.

Here is one way you may be able to use OpaVote for a project-based budget distribution use-case:

1. Run an election with a single contest with each project as candidates.
2. Take the first place project and subtract its budget from the pool of available funds.
3. Remove the first place project and all other projects that would require more budget than remain
4. Run a count against the remaining projects, establishing a new first place project.
5. Repeat steps 2 through 4 until you have a subset of projects that fit within the budget.

If you have multiple budget pools (say, infrastructure, parks, and education), you could add additional contests to the election.

I'm personally quite excited about democratic budgeting, and would love to see example ballots from organizations that are exploring this problem space, and I could imagine us designing and offering a budget-focused ballot and counting structure at some point in the future. I'd also love to hear what y'all come up with!

- Zee

[Zane Selvans]

It seems like the implementation really only has to change two things to be able to work with whatever STV counting method we like:

1. Each project needs to have its own independent selection threshold/quota (the project budget).

2. Each dollar or "voting credit" that a participant allocates is treated as a separate vote for counting purposes (but a single block for voting purposes).  It looks like this is already implemented through weighted voting in OpaVote?

I think this could work really well for our use case, since it looks like some of the budget is going to come from an outside organization that isn't an actual user -- and we really want the people doing the budget allocation to be users that are impacted by the choices and are familiar with the system. So in this case, an outside funder that's contributing $30K could (say) delegate $10K to each of 3 different users (say, university researchers without their own budget to spend) and then those users could identify their priorities and "spend" the funding that's been allocated to them in the voting process.  If we got an outside grant we could delegate the funding to users whose use case we care about even if they don't have the money to support the project financially directly.

[Zane Selvans]

One subtlety that comes up with each project having its own selection threshold is how to choose which project to eliminate when there are multiple projects remaining that don't meet the selection threshold. It seems like you could choose based on which had the smallest proportion of its budget funded, or on which one was furthest from being funded in actual dollar terms.

I think the right answer is probably to eliminate the project that's furthest away from being funded in dollar terms, rather than the percentage of its budget that's unfunded, since given the finite pool of not finally allocated votes distributed across many unfunded projects it's that distance in dollars that determines which project is least likely to be funded.

For example, if you had a $100 project that was 50% funded ($50 short) and a $1000 project that was 75% funded ($250 short) eliminating the $1000 project results in the $100 project becoming fully funded, but in the reverse case, you still have no fully funded project.

[Zee Spencer]

Yea, I think weighted votes have a place here if you expect different stakeholders to have a larger say in where the money goes. This article explains how to use OpaVote with weighted votes in a context of an HOA, which appears to have some overlap with what you're exploring: https://blog.opavote.com/2018/04/weighted-votes-with-ranked-choice-voting.html

I think whether to use absolute or relative distance from funding to eliminate projects is going to depend on the particular context. For your context, absolute value seems like the right call!

I'd be curious to hear how it goes, and if you wanted to write up a guest blog post describing your approach, I'd be happy to support you by editing and publishing it on blog.opavote.com!

- Zee

[Denis Mollison]

After hearing a talk on participatory budgeting in Edinburgh in June, I adapted my Meek STV software - CRAN R package pref - to do participatory budgeting.

I was thinking of the case of equal voters, but extending it to weighted voting is trivial as the program already allows each vote to have multiplicity; thus a vote of £1000 can be treated exactly the same as 1000 identical votes of £1.

The method is based on the idea that candidates are elected by reaching a quota, which is set in terms of votes/cost (v/c). So a project costing twice as much needs twice as many votes to be on level terms.

The quota as in Meek STV is recalculated at each stage so as to be the minimum value of v/c that ensures election.

The count stops like ordinary STV when there is not enough money left to fund any of the remaining projects in-contest. But unlike ordinary STV the variability of project costs means there are options to allocate this remainder. For example, it could be offered as partial funding to the runner-up project, and if that is declined, we could go on down the list of unfunded projects to find one that can accept - there may indeed be (at least) one for which the remainder is enough to fund it fully.

If people are interested, I might be able to get the (under-development) program up on my github page (https://github.com/denismollison) over Xmas.

[Zee Spencer]

That sounds really cool Denis! Would love to see the implementation when you get a chance!

[Denis Mollison]

Sorry not to reply earlier. It's still very much on my to-do list bt I've been caught up in other things.

D