Adopting STAR voting

I am proposing to adopt STAR voting for the 2025 Steering Council elections.

The voting method is currently fixed by PEP 13, which has a specific procedure for changes, which is partially specified in PEP 13 itself.

Assuming we can agree on how to run the vote to change PEP 13, we need to draft a change to PEP 13 that describes STAR voting.

PEP 13 currently has this on the SC election process:

Electing the council

A council election consists of two phases:

  • Phase 1: Candidates advertise their interest in serving. Candidates must be nominated by a core team member. Self-nominations are allowed.
  • Phase 2: Each core team member can vote for zero or more of the candidates. Voting is performed anonymously. Candidates are ranked by the total number of votes they receive. If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.

Each phase lasts one to two weeks, at the outgoing council’s discretion. For the initial election, both phases will last two weeks.

The election process is managed by a returns officer nominated by the outgoing steering council. For the initial election, the returns officer will be nominated by the PSF Executive Director.

The council should ideally reflect the diversity of Python contributors and users, and core team members are encouraged to vote accordingly.

The only text I’d like to change is the “Phase 2” bullet. Here’s my current best effort:

  • Phase 2: Each core team member can assign zero to five stars to all candidates. Voting is performed anonymously. The outcome of the vote is determined using the STAR voting system (www.starvoting.org). If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.

Or, in diff form:

diff --git a/peps/pep-0013.rst b/peps/pep-0013.rst
index fca214c0..cc9dd4fe 100644
--- a/peps/pep-0013.rst
+++ b/peps/pep-0013.rst
@@ -105,11 +105,11 @@ A council election consists of two phases:
   must be nominated by a core team member. Self-nominations are
   allowed.
 
-* Phase 2: Each core team member can vote for zero or more of the
-  candidates. Voting is performed anonymously. Candidates are ranked
-  by the total number of votes they receive. If a tie occurs, it may
-  be resolved by mutual agreement among the candidates, or else the
-  winner will be chosen at random.
+* Phase 2: Each core team member can assign zero to five stars to all
+  candidates. Voting is performed anonymously. The outcome of the vote
+  is determined using the STAR voting system (www.starvoting.org).
+  If a tie occurs, it may be resolved by mutual agreement among the
+  candidates, or else the winner will be chosen at random.
 
 Each phase lasts one to two weeks, at the outgoing council's discretion.
 For the initial election, both phases will last two weeks.

I have one insecurity about this draft text: maybe it should elaborate how we intend to use STAR (which is inherently a single-winner system) to select N candidates? I know how to do that but the description is a bit verbose: Basically, you repeatedly select a winner and then remove that candidate from all ballots until you have selected enough winners. But there are some special provisions for ties (a tie is a non-problem if it can be resolved by selecting the other tied candidates in subsequent steps). This seems a lot of words for a high-level document like PEP 13.

Thoughts?

Once we have rough agreement on the draft text of the change (this topic) and on the process to use to make the change official (separate topic), I will create a new issue here to initiate the vote (or do whatever else we end up choosing to make such a change).

8 Likes

Oof, STAR actually describes how to do a Multi-Winner STAR election here:

Search for the heading Multi-winner Bloc STAR.

(Or should we chose Proportional STAR? It promises smaller factions a seat if their candidate gets at least 1/N of the votes.)

Can you be explicit about why you think the change in the voting method is worthwhile?

2 Likes

I thought that was clear from the initial post (by Greg):

Basically, giving each candidate 0-5 stars gives voters more satisfaction that they can express their preference among acceptable candidates, and of the voting systems that support such expressivity, STAR is the best.

6 Likes

I think this is a pretty important difference. The current voting system is a bloc voting system, where primarily the majority is represented.

As a silly example, let’s imagine we have 100 core devs, and 60 belong to the Spaces Party and 40 to the Tabs Party. If the SC election has 5 members of the Spaces Party and 5 members of the Tabs Party running, the Spaces people will each get 60 approval votes and the Tabs people will each get 40 votes. So we end up with 5 Spaces supporters on the SC, when perhaps it would have been more fair to have 3 Spaces and 2 Tabs supporters.

With Multi-winner Bloc STAR, we’d still have this same situation, though the star system has the advantage that you can get more information about which members of the Spaces Party are preferred. With Proportional STAR instead, we’d get 3 Spaces and 2 Tabs supporters.

In practice, I don’t think we have such rigid factions in the core team as this example suggests. Still, I like that the proportional method provides a way to elect someone who is strongly preferred by a minority of the electorate. That ensures that all members of the core team are represented, not just the ones whose opinions are most in line with the majority.

13 Likes

Yes, please.

2 Likes

Unfortunately it feels like people really care about voting nuance, so being explicit here is probably worth it.

3 Likes

Possibly we could link to the “Multi-winner Bloc voting” in on the starvoting.org site? That seems precise enough to me.

1 Like

I checked and the site is archived by the Wayback Machine, so hopefully that’s enough to alleviate any concerns about the site changing from underneath us in a meaningful way (I’m personally not worried FYI).

2 Likes

Just to clarify my understanding… Each core team member can assign zero to five stars for each candidate on the ballot.

I agree with @Jelle’s summary as well.

1 Like

New draft diff:

diff --git a/peps/pep-0013.rst b/peps/pep-0013.rst
index fca214c0..24f97cc5 100644
--- a/peps/pep-0013.rst
+++ b/peps/pep-0013.rst
@@ -105,9 +105,11 @@ A council election consists of two phases:
   must be nominated by a core team member. Self-nominations are
   allowed.
 
-* Phase 2: Each core team member can vote for zero or more of the
-  candidates. Voting is performed anonymously. Candidates are ranked
-  by the total number of votes they receive. If a tie occurs, it may
+* Phase 2: Each core team member can assign zero to five stars to each
+  candidate. Voting is performed anonymously. The outcome of the vote
+  is determined using the STAR voting system (www.starvoting.org),
+  modified to use the "Multi-winner Bloc STAR" approach
+  (www.starvoting.org/multi_winner). If a tie occurs, it may
   be resolved by mutual agreement among the candidates, or else the
   winner will be chosen at random.

If we end up preferring Proportional STAR, just change “Multi-winner Bloc STAR” to “Proportional STAR”. But I feel that still needs to litigated (I can imagine some pretty unworkable SC configurations if we were to do this). I do like Jelle’s clear explanation of the difference though.

Once we are voting on a PEP 13 change, could we also make a small benign change to the text? Łukasz is planning to update the devguide to include the ultimate poll template to use for voting on new committers, to avoid mistakes or inconsistencies on how polls are created. It would be nice (once that devguide update is live) to be able to hot-link there from PEP 13. Presumably the hot-link would be a sentence added to this paragraph:

It is granted by receiving at least two-thirds positive votes in a core team vote that is open for one week and is not vetoed by the steering council.

Perhaps:

The devguide has a template to use for such votes: (link).

I also noted that PEP 13 has a list of amendments near the end. This should be updated appropriately, e.g.

2024-XX-XX: Switched to Multi-winner Bloc STAR voting; added link to template for new core devs votes.

To make it extra clear that the devguide isn’t an official part of the “constitution”, I’d make it:

… note::
The devguide has a suggested template to use for such votes: (link).

And since the devguide might turn to a contribution guide, add some lawyering to Changing this document:

No vote is required to update note blocks and the Current steering council and History of council elections sections with current information.

5 Likes

Okay, posting the updates here becomes tedious. I’ll just point to the Draft PR I’ve created. Assuming there’s rough consensus that a Discourse poll is enough to get this amendment approved by the Committers group, we can bikeshed a bit more and next week I’ll post that poll (open for two weeks).

Note that there’s still an open discussion about Block STAR vs. “Proportional Representation” STAR in other threads:

Whoops. I didn’t actually link to my Draft PR. :slight_smile: Here it is:

While this sounds like a good model, there’s also a downside.

To quote from the starvoting website: “Voters have … and less power to vote out an elected official who they strongly oppose. For example, in an election with five seats up for election, over 80% of voters would need to oppose an incumbent to prevent them from winning re-election.”

This becomes worse if you have more than just 5 seats.

OTOH, multi-winner Bloc STAR and approval voting have a similar problem: if you want to vote out an SC member of the prevailing party, you not only have to get support for this from the other parties, but also convince the prevailing party’s supporters that this is better for everyone.

In real life this hardly ever seems to work. It’s more common for the ratios to get shifted completely, so that the currently prevailing party doesn’t receive enough seats anymore to have the incumbent reelected. In your example, this would be a shift from 60:40 between spaces and tabs to e.g. 40:60.

Even though this appears to be harder to achieve, real life shows that it’s often easier to vote out complete parties than individuals you are opposing, so my gut feeling is that multi-winner Bloc STAR and approval voting tend to give voters more power in such a case.

Now, all that said, in our case, with just 5 seats, and based on my experience having been on the PSF and the EPS boards, I actually think it’s better to have more differing opinions on the SC, leading to more discussion and scrutiny on decisions, than simply having a block of folks who all think in the same direction.

So even though there may be a problem voting out an individual, I believe that we’d benefit more from proportional STAR and I’d be +1 on this method, while only lukewarm on multi-winner Bloc STAR (it doesn’t give us much advantage of approval voting).

7 Likes

Me too! Which is why I’ve been so honored to served on the SC with the amazing folks I have. It’s true that we try to communicate our decisions with one voice after seeking consensus. Leading up to that, there is always very healthy, respectful debate among folks with different opinions, insights, and experiences, and I firmly believe that helps us come to the best decisions possible solely based on what’s best for Python and our community.

7 Likes

I have some news.

First of all, I have settled on the following draft text. This uses Bloc STAR voting. (More about that later.)

-* Phase 2: Each core team member can vote for zero or more of the
-  candidates. Voting is performed anonymously. Candidates are ranked
-  by the total number of votes they receive. If a tie occurs, it may
+* Phase 2: Each core team member can assign zero to five stars to each
+  candidate. Voting is performed anonymously. The outcome of the vote
+  is determined using the `STAR voting system <https://www.starvoting.org/>`__,
+  modified to use the `Multi-winner Bloc STAR <https://www.starvoting.org/multi_winner>`__)
+  approach. If a tie occurs, it may
   be resolved by mutual agreement among the candidates, or else the
   winner will be chosen at random.

Next, after looking at the Google-Forms-based STAR voting (implemented in JavaScript IIUC) at Google Forms - STAR Voting, I emailed their help line (elections@equal.vote) and they are suggesting that we use their new (beta) self-service system at bettervoting.com. I have some more questions for them, but it looks like this system is sufficiently secure to run the SC election in November 2025. Moreover, It looks like it can tabulate the votes two ways: using Block STAR (which determines the outcome of the election) and using Proportional STAR (to compare how this differs in practice from the simpler Block STAR). We can use this to evaluate the ballots using both tallying algorithms, and if we find that Proportional STAR gives different results, we can discuss a future change to PEP 13 to use Proportional STAR instead of Bloc STAR. This probably requires several years of experiments, since we only have one election annually.

But initially I propose to use Block STAR, since its algorithm is much easier to explain to voters. (The ballots look the same either way, but the tallying differs.) Since the ballots will be public (but anonymous), others can easily write code that compares how yet other tallying methods might work giving an election’s set of ballots.

Unless there are still objections to the above PEP 13 changes (plus some administrative changes you can get from my GitHub Draft PR), I will start a Discord Poll soon to to adopt these changes to PEP 13.

According to the PEP repo’s instructions (repeated at the top of the PR description), such a change must also be approved by the SC – though I’ve already heard some SC members saying that they’re not touching PEP 13. They can still approve the changes though. :slight_smile:

12 Likes

I think this data would be fun. Reading PEP 13 it just says “Voting is performed anonymously” — while we’re here, is it worth clarifying in the PEP that ballots are public (and anonymous)?

2 Likes

Good point. I suppose I can ask Ee (but they might get tired of my endless questions about elections).

But PEP 13 doesn’t say that the anonymized ballots must not be given to vetted researchers, and redoing the poll to be more explicit about this feels like a bit of a time waste at this point.

(I also find it annoying that the draft was up for viewing for over a week and nobody commented further, and now that the poll is out people suddenly start suggesting changes.)