Why limit to 5 votes?

Committers
1

Sorry, it’s a bit late to ask this, but I hadn’t thought about it before. I don’t understand why we cannot vote for more than 5 candidates. The way I understand Approval voting, you vote for anyone you consent to have as a representative: it doesn’t matter how many seats are actually offered. Why are we doing things differently?

The game theoretical properties of Approval voting hold for the original version (where you are not limited in the number of candidates you approve). Do they hold when you are limited in the number of candidates you can approve? It doesn’t seem obvious.

For example, let’s say there are 6 candidates A, B, C, D, E, F that I would like to approve (*). I am forced to choose a subset of 5. Perhaps I prefer E over F, so maybe I should not include F in the final ballot? But if I have the intuition that E has a much smaller chance of winning, choosing E over F could prevent F from winning while not letting E win either. In normal Approval voting, I don’t have to solve such a tactical puzzle.

(*) It’s not far from the real situation :wink:

5 Likes
2

I had assumed that we’d be using CIVS and Condorcet again, so approval voting was a surprise. I don’t understand how people stay on top of these things in a fragmented Internet Forum.

1 Like
3

Condorcet isn’t really appropriate for an election where you want multiple winners. You can kind of fake it with Condorcet methods that attempt to generate an overall ranking, but even then you’re going against the intended use.

Approval voting isn’t called out by name in PEP 8016, but voting for up to 5 candidates is. The wording rules out Condorcet and limits it to up to 5 votes. The related discussion did call out Approval voting by name (we should probably clarify in the PEP). Allowing more than 5 votes would require an amendment to the new PEP13.

2 Likes
4

Agreed. I hadn’t expected this. I’d more or less assumed that I would at least be able to order my choices by preference. At a minimum, an explanation of how to vote (with a pointer to where it was discussed/agreed) should have been included with the announcement.

However, what’s done is done, I guess…

5

You just can’t stop nerds from inventing a new voting system every time they have to vote :wink:.

The “if there are 5 ultimate winners, vote for at most 5” scheme is an instance of what’s called “first past the post bloc voting” here. As that brief article implies, at least in the presence of political factions it sucks for the same basic reasons the “first past the post” (plurality) single-winner scheme sucks: because the number you can vote for is limited, the pressure is high not to vote for your true favorite(s) if you guess they can’t win, but people who vote for doomed true favorites anyway can “split the vote”. The vote(s) they “waste” voting for the doomed are votes that may be taken away from what would otherwise have been consensus winners.

But neither approval nor Condorcet were designed with multiple winners in mind either. The specific Ranked Pairs Condorcet method was designed to produce a total ordering (which is, indeed, Schulze’s complaint about it: Schulze only cares about single-winner elections, and optimizing for a total ordering may not produce the same choice in the #1 spot as optimizing for a single winner).

But in the absence of political factions, there’s really little to object to in plain Approval (approve of as many or as few as you like) voting for a multi-winner election. That’s why David Mertz pushed it through for PSF Board elections long ago. And it remains an improvement over its successors so far :wink:.

Highly regarded multi-winner systems in the presence of political factions involve all sorts of complications to ensure that a minority faction has a good chance of getting a share of winners roughly equal to that minority’s share of the electorate.

For example, in “reweighted range voting” everyone gives scores to candidates (approval voting is like that with the only scores allowed being 0 or 1). The candidate with the highest total (or average) score is one of the winners. Then every score on every ballot is effectively adjusted, so that ballots who rated the winner highly carry less weight for the next round (“you already got much of what you want, so let’s give minorities a chance too”). Lather, rinse, repeat.

But in the absence of that, you just can’t beat plain approval or range voting for simplicity and transparency. Limiting approval voting to at most 5 approvals in a 5-winner election is a Highly Dubious Idea on the face of it, according to me - gratuitous novelty.

6 Likes
6

There shouldn’t have been a limit as it reduces the power of the approval voting system. Too late now but I hope we can fix it in the future.

I am a strong supporter of approval voting, at least for elections were there are many voters (e.g. state/provincial and federal elections). In the voting of the council, because we have a small number of voters, maybe a system that allows ranking would be slightly better.

7

It can be fixed yes. PEP 13 – Python Language Governance | peps.python.org

3 Likes
8

You just can’t stop nerds from inventing a new voting system every time they have to vote :wink:.

Perhaps we should use the ultimate nerd system Schulze STV (https://arxiv.org/pdf/1804.02973.pdf), which on the surface appears to be an adaptation of Schulze/Condorcet for multiple winners. :wink:

“Schulze STV is motivated by the fact that we want a generalization of the
Condorcet criterion from single-winner elections to multi-winner elections
that is as strong as possible…”

9

I think Tim’s point was that newfangled systems are generally a bad idea, especially ones invented “on the fly”. He said “you just can’t beat plain approval or range voting for simplicity and transparency”. Removing the limit of 5 selections would be simplest fix. I think Helios does not support range voting so that would be a bit more difficult.

2 Likes
10

Nothing was invented on the fly… “up to N” approval voting is very common in practice. In particular, this is the same system Django and the PSF both use. (If it was something we just invented, then Helios wouldn’t have support for it built in :-).)

I’ve had trouble in the past finding explanations of how pure approval and at-most-N approval differ, or why you might prefer one to the other. (I haven’t looked at Tim’s links yet; maybe they’re what I’ve been looking for.) So in the absence of any better reason, we picked the one that’s more popular/familiar.

One common complaint about pure approval is that voters struggle to set their “threshold”. Should you vote for your top 1, your top 5, your top 10?, …? At-most-N does at least give voters some guidance here.

1 Like
11

Don’t know anything about Django. But it was news to me that Helios even allowed limiting the number of Approval votes. Like in our own election docs:

Here, fill out the question(s) on the ballot. For example in a Board of Directors Election, fill out the name and link to their candidacy statement on the PSF wiki. If there are 10 candidates, voters should be able to pick between 0 and 10 answers. The election should be an absolute election.

That is, “if there are 10 candidates”, then “voters should be able to pick between 0 and 10 answers”. Pure Approval voting, which was intentional from the start.

As to why, I think I already gave sufficient explanation. In the limit, at-most-1-choice degenerates to one of the worst - but also one of the most “popular” - voting systems on Earth: straight plurality. At-most-N-approvals suffers similar pathologies: strongly discourages approving your true favorites if you think they don’t have a real chance to win (then the limit forces you to approve someone you want less to avoid “wasting” your vote), and people who vote for their true doomed favorite(s) anyway can split the vote for a candidate who would otherwise be a consensus winner (because the vote(s) they wasted on their doomed favorite(s) can’t also be used to approve of candidates they nevertheless like “well enough”).

Yet across the years we’ve been using actual Approval voting for the PSF Board, I don’t believe that’s ever been asked :wink:. “Do you, or do you not, think this candidate is a reasonable choice?” is the only thing an honest Approval voter needs to consider. “Well, I think 6 are reasonable, but it will only let me approve 5” isn’t really helping anyone, is it?

Note that we had exactly that “problem” when a poll was constructed here about which voting methods people thought were acceptable for the governance vote. The initial poll didn’t allow picking all the available choices, and it was quickly abandoned and replaced with a poll that did allow people to approve of all.

12

Huh, I could have sworn that the last time I voted for the PSF board, there was a limit on how many boxes I could tick. Maybe I just hallucinated that?

Anyway, I’m not particularly defending the at-most-N variant, just explaining how we ended up with it. It was in the Django text we started with, it didn’t jump out at us as something that needed changing, it didn’t jump out at anyone who read the proposal as something that needed changing, and here we are. It’s too bad no-one noticed this back during the review period when it was easy to change, so I guess we’re stuck with it for this election, but if people want to revise it for the next one then I won’t stand in your way :-).

It might make sense to collect up several small “amendments” like this to handle all together, a few months from now once things have settled down. I know Łukasz would like to tweak the council term to decouple it from the release cycle, and probably we’ll run into a few other nits as we start using the new system for real.

13

That’s my guess :wink:. I saved the email announcing the 2018 Board election, and it let me log in even today. There were 17 candidates, and the instructions say “vote for up to 17”. What I never noticed before was the “up to N” part, and I don’t know whether that was “a new feature” at some time, or that limiting the number of approvals is something that was always supported but that we never used for Board elections (apart from forcing to the number of candidates). In any case, since I was there at the start, I can testify that “pure Approval” was the intent.

+1. Until then, we’ll live :wink:

2 Likes
14

Aye, if I’d noticed I’d have recommended changing it to exactly match the PSF Board elections (which are simple approval with no limit on how many Yes votes you submit).

As it is, the limit makes the voting a bit more like a “Define your own election ticket” model, where rather than expressing “Which candidates would you be happy to have on the Steering Council?” we’re instead expressing “Which Steering Council make-up do you think would best serve the core development process?”.

It’ll be interesting to see how it turns out, as I know one of my concerns was that veteran contributors might gain a large number of “Sure, I’ve trusted them for this long, and I still trust them now” votes in the pure Approval model, and that seems less likely to happen when we can only vote for exactly the set of Council members we want to see.

2 Likes
15

I don’t know of any body of simulations testing this, and intuitions vary. I expect the opposite :wink:. The article on this I linked to before notes:

The bloc voting system has a number of features which can make it unrepresentative of the voters’ intentions. It regularly produces complete landslide majorities for the group of candidates with the highest level of support, though this does tend to lead to greater agreement among those elected. Like first past the post methods, small cohesive groups of voters can overpower larger numbers of disorganised voters who do not engage in tactical voting.

Of course people differ. For me, if I can only approve of 5, I’m most likely to vote for the 5 I’ve known the longest and best, rather than “risk” approving someone I guess will do well but don’t have that long confirming experience with. In fact I think more than a few of the latter would be reasonable choices, and so would approve them if there weren’t a limit. But, with a limit, the election is no longer asking who I think would be reasonable choices.

For us, without political factions scheming to elect cabals, I’m more concerned by possible second-order effects: if it turns out most voters are “like me” in the above respect, the quoted paragraph’s “complete landslide majority for the group of candidates with the highest level of support” will obtain, and promising non-winning candidates will be discouraged by getting very few votes (they’re on the buried end of the “landslide”). Without a limit, some number of those may see instead they actually had high (even if not quite enough to win) approval levels.

1 Like
16

I don’t share that concern, since I happen to think that having seasoned contributors in the Council is better than having unproven newcomers :wink: Like @tim.one, if you bound the number of candidates I’m allowed to approve, then I’m gonna select those I’m have the most confidence in, and those are obviously (as far as I’m concerned!) people who have been contributing for a long time, and have dabbled in many different areas… rather than some newcomer who’s very knowledgeable in one particular area but hasn’t made sizable or very diverse contributions yet.

3 Likes
17

Now that the results are in, this seems likely. Personally, I would have been fine with any of the candidates serving on the council. I hope people with low vote counts are not discouraged. I voted strategically and did not vote for candidates I thought were unlikely to have a good chance of winning. I didn’t think about the effects of vote tallies being published.

2 Likes
18

I posted the following in a reply to Guido on the committers mailing list, but it really fits better here:

Ir was already speculated about before the election :wink: As predicted
by a brief article I linked to on Discourse, limiting the number of
approvals to 5 favored a landslide victory of the best-known
candidates. Except for Nick, the weakest “winner” got 50% more
approvals than the strongest “loser”. So “landslide” for 4.

In pure Approval voting (which we’ve used for PSF Board elections),
there is no limit, and then you get a clear picture of approval
levels. The “losers” here should realize their relatively low
approval levels may be an artifact of the voting process. Like in
“first past the post” plurality elections, with a limit there’s
pressure for voters to betray their actual favorite(s) if they think
they can’t win, to avoid “wasting their vote”. Without a limit,
there’s never a reason (regardless of whether a voter is 100% honest
or 100% tactical) not to approve of your true favorites.

In the Discourse discussion, there seemed to be consensus that
limiting to 5 was probably a mistake, but it would require a change to
some PEP to remove the limit, and the issue didn’t come up before it
was too late.

Beyond that, pure Approval is just unsuitable if there’s some goal
to achieve some level of “diversity”, in an extremely broad sense.
While we don’t have political parties, we are developing factions,
like “old-timer vs new-comer”, “conservative vs aggressive” wrt
language changes, and so on. Some form of “proportional
representation” voting is needed if we want to cater to that (and,
yes, there are variations of Approval voting that address such
concerns - but they’re all more complicated and I doubt Helios
supports them).