How to enact changes to PEP 13

Following the discussion on changing the voting system for the Steering Council, I feel it’s pretty clear that STAR voting would be the preferred voting system over the current Approval Voting system:

I am thinking about how to actually implement this change (for the 2025 election – the 2024 election is too soon to make such changes):

  • First we need to make sure that we have a way to actually run a STAR vote. I think this is a question for Ee, who runs our elections for us. I will email them.
  • In parallel, we need to draft a change to The second bullet of the section Electing the council in PEP 13.
  • Then, we need to follow the correct process to change PEP 13.

This post is mostly about the last bullet. PEP 13 itself says:

Changes to this document require at least a two-thirds majority of votes cast in a core team vote which should be open for two weeks.

It doesn’t specify how to run this vote. The simplest way would be to open an anonymous poll in the Committers category in Discourse (i.e., here), with the text of the proposed changes, and a choice of “Accept” / “Reject”. We might also have to send email to all committers (is there still a mailing list for that?) to reach those folks who don’t regularly read Discourse (that includes me, since June of this year :-).

I’m adding an informal poll to this message asking whether folks generally think that this is a sufficient way to enact changes to PEP 13:

  • Yes, a Discourse poll in the Committers category (with 2/3rd majority) is sufficient to change PEP 13
  • No, we need a heavy-duty vote (like the SC elections) to change PEP 13
0 voters
3 Likes

For historical reference, when the voting method was changed from “approval vote for up to 5 candidates” to “approval vote for as many as you want” in late 2019, it was done via a poll run here on Discuss.

That vote only garnered 33 total votes with a single one against. Though notably did not include an “no opinion - don’t count me” category so those who simply didn’t care aren’t represented any different from those who didn’t see the poll.

We already promote new committers (read also as: new voters) via vote here on Discuss.

If we want to be more formal in this process, Discuss still seems fine (IMNSHO), but we could do a direct email to all voters to reach out ahead of time to help ensure they see the poll, similar to what is done for the more formal SC election itself.

3 Likes

My only concern with using Discuss is the security/validity of the accounts voting. If it is as secure as the method used for SC elections, I am happy to change my vote to Yes.

2 Likes

I did a quick search online, looked in the admin console, and saw what settings I had for Guido’s poll and I don’t see a direct way for an admin to change anyone else’s vote. So I guess maybe someone at Discourse could alter the database directly since this is a hosted instance? But I don’t know how much more/less secure that is than the trust we place in the systems we have used previously to vote.

If you’re asking about the security of individual accounts, I can’t speak to how secure people’s email accounts are compared to Discourse, so I don’t think that’s better/worse.

5 Likes

Thanks for checking, switching my vote to Yes. :slight_smile:

5 Likes

Ee’s response came quick: our current voting platform, Helios, does not support STAR, but they are not against chucking Helios (it’s becoming more problematic over time). We just need to find a platform that does support our preferred form of Multi-winner STAR voting (Bloc or Proportional).

Maybe @larry has insights here? (He wrote that he maintains his own STAR voting implementation.)

Yep, I wrote starvote, an election tabulator that supports STAR Voting and several of its variants. (pip install starvote !) But I assure you I’m not an election scientist–just an interested, mildly-informed amateur. So I’m not sure how much expertise I have to lend. I’d feel better if we simply tabled this until a certain banned community member returns in a month or two, as they’re an expert in these areas and can speak with far more authority. Though I’m willing to answer questions in the interim as best I can.

It seems to me that Helios brought a lot of other trappings like “here’s a hash that guarantees your vote was counted” and other stuff I didn’t really understand but seemed nice. I liked the “you can vote as many times as you like, we’ll only keep the last one” feature even if I never needed it. I assume there’s a lot of porcelain and plumbing that we (or someone) would need to reimplement if we want to abandon Helios and host our own elections, and voting is important enough that you want some assurances that it was conducted fairly and accurately.

FWIW, STAR Voting is pretty easy to tabulate. I spent a lot of time in my library hammering out the API and sorting out tiebreakers–the latter of which I’m assured are exceedingly rare in real-world elections. (My library does maintain 100% coverage though, which I find reassuring.) The multiwinner variant, “Bloc STAR”, is only slightly more complicated. The proportional representation variants got very complicated however.

I think I’d prefer simple multiwinner (“Bloc STAR”) to a proportional representation scheme.

First, a clarification on terminology: “STAR-PR” is not a specific electoral system. It’s a label given to officially-approved STAR Voting electoral systems that support proportional representation. So far there’s only one such approved system, “Allocated Score Voting”. (As a result, sloppy people use “Allocated Score Voting” and “STAR-PR” interchangeably. I’m pedantic enough that I try to avoid it.) My starvote library implements three STAR-Voting-ish schemes for proportional reprentation, including Allocated Score Voting.

Here’s the problem proportional representation solves: if 60% of your populace is Republican, and 40% is Democrat, and you have five seats on the city council, how do you want to fill them? In a straight multiwinner election, the majority would presumably vote in five Republicans. Is that best? “Proportional representation” means you’d allocate the winners based on them representing portions of the electorate; in the example I just gave, a PR scheme would likely elect three Republicans and two Democrats. Is that better? Maybe! Or maybe not! Which scheme leads to better results is highly subjective.

Often proportional representation is done by organizing around / voting for political parties. That’s called party-list proportional representation, and it’s used all over the world. But we don’t have political parties in the Python core development electorate.

Lucky for us, the STAR-Voting-adjacent PR schemes work in a different way, that doesn’t require political parties. But what they do is hella complicated. I cover it in detail in the starvote README, but in a nutshell: when the electoral system elects a candidate, all the ballots that helped elect that candidate are weakened (“re-weighted”) or outright thrown away (“allocated”). It’s like, you won, your vote is represented in the outcome, you’ve had your say. Now we need to amplify the ballots from the other voters who haven’t gotten anyone elected yet, and we do that by reducing how much your ballots count in subsequent rounds.

“Allocated Score Voting” is frustrating because it gives up one of the design tenets I like about STAR Voting. In STAR Voting, every vote is always counted, in every round; at no point is a vote ever thrown away. (Unlike IRV.) Unfortunately, “Allocated Score Voting” does allocate votes, meaning it does throw them away. That’s also true of “Sequential Score Voting”, an electoral system I implemented just for fun, just because I was curious about it. Of the PR systems I implemented, only “Reweighted Range Voting” never throws away votes. So I find that more appealing. (Technically “Reweighted Range” isn’t a STAR Voting variant, it’s a Score Voting variant. It doesn’t have STAR’s runoff round. AFAIK none of these methods are widely used, though Reweighted Range is now used to pick the five nominees for the Oscars in one or more categories.)

Another downside: all three PR schemes use a lot of fractions. That’s one feature of my starvote library: I use Fraction objects for all the tabulation, never floating-point. My tabulation is 100% deterministic and never ever loses precision. But with all three PR methods, this does have the downside of making the output look ridiculous. Here’s some sample output from one of my test cases:

[Reweighted Range Voting: Round 5: Score round]
The highest-scoring candidate wins a seat.
  Jo Jorgensen      -- 866+  46490201/81124680   (average   70300463081/235991694120)   -- First place
  Adam Kokesh       -- 838+ 254151133/535422888  (average  448938531277/1557545181192)
  Daniel Behrman    -- 724+  64381511/178474296  (average  129279771815/519181727064)
  Sam Robb          -- 572+     25687/1312311    (average     750667579/3817512699)
  John Monds        -- 552+  69926651/76488984   (average   42291845819/222506454456)

(One of my todo items for starvote is to use floating-point, but just for presentation. Tabulation would still strictly use Fraction, but at the end when I print out the result I think I should convert to float and only print a couple of decimal places.)

Bloc STAR isn’t a PR system, and tabulating it never requires fractions. It’s far simpler to tabulate than any of the PR systems, and therefore it’s easier to get right and (if necessary) to verify by hand. I think I’d prefer straight multiwinner to this squirrely proportional representation stuff.

6 Likes

(@larry)

I think I’d prefer straight multiwinner to this squirrely proportional representation stuff.

That’s thinking according to PEP 20:

If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.

It’s seductive, and I do worry about how PR would be implemented. But I can also see why some people would strongly prefer proportionality. Maybe we’ll have to put that in a separate Discord poll first… (At the risk of boring everyone to death with all the Discord polls. :slight_smile:

2 Likes

The poll’s been closed for a while now (and I’ve been distracted, sorry) but out of 33 voters, 29 voted for a Discourse poll to change PEP 13, and only 4 voted for a heavy-duty vote. So the Discourse poll wins with roughly 87.9% of the votes, and that’s what we’ll do.

The next step is now in Adopting STAR voting - #7 by brettcannon, where I am trying to come up with a definite diff to PEP 13 on which to vote. I will follow up there with an update to.

3 Likes

How feasible would it be to do a one-off mass email to the usual python/voters email list with a link to the Discourse poll?

There are periods of the year where I look at Discourse much less frequently due to life & other commitments, so it might be possible to miss a poll altering PEP 13, whereas the email at least is a ‘push’ to each member of the core team. I don’t know if this applies for others, but two weeks can pass remarkably quickly!

I appreciate that this somewhat defeats the object of a lightweight poll on Discourse, but I think for changes to our governing document we should attempt to notify everyone who has the right to vote, even if we use a simpler mechanism of voting.

A

8 Likes

I second Adam’s concern.

Proper governance requires proper voting and if you don’t at least let all voters know that there’s a poll underway, you fail to meet that requirement, rendering the results of the polls highly questionable and any actions taken as a result of such polls incompatible with what PEP 13 intends to promote.

BTW: I find it somewhat ironic, that a change to use a different voting scheme for our governing body elections is going to be voted on using a simple poll. We might as well ditch the whole voting scheme complexity and go full-in on Discourse polls :slight_smile:

IMO, we should err on the side of what PEP 13 most likely meant to say, which is to use the same voting scheme for all votes it discusses. It’s easy to do this combined with the upcoming SC election.

5 Likes

Agreed, a “howdy, there’s a vote on” email with the link to the Discourse post is feasible and is quite reasonable for anything making a substantive change.

6 Likes