PEP 801x authors, are you on track for the vote between Nov 16 - Nov 30?

All of those were supposed to happen between Oct 8 (the deadline for all PEPs to be published) up until before the voting start. Once voting start (Nov 16) the PEPs are meant to be in “ready to vote” form, and no further changes should be made.

I would suggest that we keep with the original plan (using CIVS).

  • Returning to edit responses requires the user to copy/save the edit link explicitly

Based on my experience running surveys via Google Forms, people will forget to copy the link and will bother the organizer to please edit their entry. The Python Language Summit chairs (Larry, @barry, and @ambv) can probably attest to this. Some of you might be familiar that we used Google Forms to gather talk submission to Language summit, and people did forget to copy their form submission link.

It happened quite often, and there’s nothing the form owners can do about it.

If form submissions require pasting in a unique id, then presumably the vote administrator can just ignore everything except the last vote that used a given id…?

@barry, @njs, you both commented but didn’t respond to my questions above.

Sure, it just adds more work and burden to the administrator (and I’m grateful that @EWDurbin is willing to help with this)
While that is possible, it would be nice if we could just be more responsible and own our decisions. If you’re not ready to vote, then don’t vote.

If you’re worrying about people are end up voting for different things, well those are up to each individual voters. they can make their own decision of when to vote, we can’t control it.

With the upcoming USA Thanksgiving holiday, I would propose to begin voting on December 1. I see on python-committers that it’s not just us that are uncomfortable with starting the vote tomorrow. This is a crucial decision for the Python community, so I think it’s important to get it right, and some committers are feeling disenfranchised. The vote deadlines are artificial, so I see no problem with a reasonable delay.

1 Like

Thank you, Barry. Could you open a pull request to PEP 8001 with this plan? We’ll get all other PEP 801x authors to approve it and then we’re done with the controversy.

We can explicitly call this period from tomorrow to December 1st the “review period”. I don’t think it’s reasonable to expect PEPs to be frozen in this period but we might recommend against substantial changes.

This also gives @njs and others time to maybe come up with a replacement for CIVS for PEP 8001.

1 Like

https://github.com/python/peps/pull/841

I’m actually disappointed that we keep delaying things and bringing up last minute issues. I find it disrespectful towards the effort that the others have made in order to meet the agreed timelines.

4 Likes

Well, I started a poll earlier asking about the voting windows people would be comfortable with. Response was underwhelming, and I closed the poll when @ambv opened this poll. At that time, I was the only voter who had approved of any window other than the original (16-30 Nov).

Complaints at the last second are predictable, but why should we believe that would stop just because we pushed the start to 1 Dec? Since you suggested it, you might be too shamed :wink: to complain again, but what of the others? Despite @ambv’s multiple attempts to get people to be specific about what they want instead, you’re (unless I missed some in today’s crush of messages) the only one who was specific.

OK by me, but just about anything would be. Can we get, e.g., @njs and @malemburg to explicitly agree? Else I just expect complaints to resume on 30 Nov.

In three US states, early voters can change their vote. I only know that because I happen to live in one of those states - it’s certainly unusual.

Noting that this form doesn’t appear to allow for ties, but ties are fine in Condorcet elections (“I have no preference between PEPs A & B”). CIVS ballots make that quite plain, and have shortcuts to multi-select your tied choices and adjust all their ranks to be equal with one click, also automagically re-sorting all choices from most to least preferred whenever you change a ranking.

That’s the kind of stuff people learn how to do over time, via actual real-world experience using a system for running many votes, and improving them in response to problems (real & perceived) that come up.

So, in general, ya, I’d rather use battle-tested software than schemes we come up with off the top of our heads. But we’ll live either way.

CIVS will also, e.g., tell us instantly whether there is or isn’t “a Condorcet winner”, and, if not, how several highly regarded Condorcet methods would resolve the dilemma. While the latter is just “nice to have”, the former is crucial for this election. Of course we can write our own software to do that too. The difference is I already wholly trust that CIVS gets that part right :wink:.

I don’t understand why the voting method is still being discussed. It has been decided, no?

Ties are actually new to me. Wikipedia is full of “citation needed”:

How are ties (no preference for multiple PEPs) counted? Is this …

… authoritative?

I’d say details of voting methods are off-topic here. So, briefly, you can require pairwise distinct rankings on a Condorcet ballot, but there’s no need to, and forcing people to fabricate preferences they don’t actually have is distasteful on the face of it.

All these methods build on constructing a 2D matrix M such that M[i, j] is the number of ballots that ranked candidate i higher than candidate j.

For a ballot A > B > C,the entries M[A, B], M[A, C], and M[B, C] are incremented.

For a ballot A > B = C, only the entries M[A, B] and M[A, C] are incremented.

At heart that’s all there is to it. Where Condorcet methods vary is in what they do with the info in M. Some can be coded a little easier if it’s guaranteed that M[i, j] + M[j, i] always equals the total number of ballots, for all i != j pairs. All the methods implemented by CIVS couldn’t care less about that, though.

1 Like

Thanks, Tim! To get back on topic, I find it a little late to ditch CIVS in favor of a Google form + trusted PSF handling.

I dropped out of that discussion because I was sure that CIVS was the chosen method.

Please discuss voting in a different topic. That’s off-topic here.

The vote is supposed to start tomorrow. Is it the case or not? @barry created https://github.com/python/peps/pull/841 which isn’t merged yet.

I discuss it here, because https://github.com/python/peps/pull/841/files has been posted here and contains a paragraph that E.W. Durbin is supervising the votes.

The rest of the thread caused me to assume that this means CIVS has been ditched. But I have trouble following discussions on Discourse.

@skrah and I had already agreed it was off-topic here, and that’s where the tiny sub-thread would have died, all by itself. Meta-posts about what other people post just resurrect dead ends. Which - yup! - I risk doing too by making this meta-comment. Just let it die?

Yes, but because he agreed to be our election supervisor for the CIVS voting process - which is “old news”. PEP 8001 still specifies that we’re using CIVS (& Barry’s PR doesn’t change that - it just changes the vote dates).

1 Like

Now that the vote has been postponed by two weeks, this thread is basically finished. Any other discussions should be started as their own topic.