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

It would be nice to officially approve the PEP 8001 if we decide to keep the current schedule (start voting tomorrow): https://github.com/python/peps/pull/839 Otherwise, it sounds awkward to start voting while the PEP is still a Draft :slight_smile:

Agreed, which is why this poll is closing in 11 hours.

First I wanted to get a sense of what status the PEPs are in. @njs and @dstufft didn’t respond and I mostly wanted them to, in order to get a sense of how much additional time (if any) are they asking for.

I still hope they will let us know by noon PST.

I’m guess I’m in a similar position. PEP 8016 is in a pretty solid state as far as I’m concerned (not sure why everyone in the other thread started accusing me of being lazy or something – this was never the issue). But, I don’t think the community discussion or PEP 8001 are in a state where it would be OK to start the vote tomorrow.

I am still concerned as well, that my own PEP 8015 is “not perfect”. So I wrote it in the PEP, § Change this PEP:

The first version of this PEP has been written after Guido van Rossum decided to resign from his role of BDFL in July 2018. Before this PEP, the roles of Python community members have never been formalized. It is difficult to design a perfect organization at the first attempt. This PEP can be updated in the future to adjust the organization, specify how to handle corner cases and fix mistakes.

This makes me less concerned, but I am still very nervous because I still modified my PEP… today… one day before the vote :smiley: (I am ok with myself, it’s still before the deadline, and I am now confident that my last minute change is a good one, multiple people told me that it’s good.)

But I consider that the PEP 8015 is what I wanted to propose, it should be more or less solid and consistent. I like the idea of not being allowed to modify my PEP anymore, so I can stop worrying :smiley:

@njs: I like your PEP (yep!) and it seems complete and solid. As I wrote, it’s ok if there are minor flaws, they can be fixed later :slight_smile: What matters is the main guidelines, how the council is elected, how council takes decisions, how PEPs are approved, etc. I don’t think that you are going to change that. (Are you?)

I also like the diversity of governance in the 7 proposed PEPs. It’s nice to have the choice! It seems like July to November was long enough to have this diversity.

@njs, what are your concerns with PEP 8001? How else would you like the community discussion to look like? Please give me some concrete suggestions.

I’m a bit confused about whether I should be answering this here or there… oh well.

I let this sit all day today to calm down and try to see if I could reconcile myself to moving ahead. But I keep coming back to this post I made earlier:

That was in the discussion about changing PEP 8001 so that it became impossible to change your mind after casting your vote. If we start the vote tomorrow, with the current setup in PEP 8001, then I think it’s extremely likely that we’ll end up in a mess where people who vote early and people who vote later are voting on different things, and everyone’s going to end up frustrated and doubting the results.

It would definitely be less scary to me if we adjusted PEP 8001 to allow people to change their votes. AFAICT the main disadvantage is just that we wouldn’t be able to use CIVS’s voting service, so we’d need some other mechanism for collecting the votes (e.g., ask @EWDurbin to set up a google form and tabulate results, or something like that). As long as we trust @EWDurbin to keep the votes anonymous I think this would satisfy everyone. But there would need to be some logistics to figure out (that’s the part CIVS helps with), and you’d want to make sure Tim and Donald are actually satisfied instead of relying on my guess, and I’d still find this somewhat aggressive and scary, and Barry apparently is concerned about the timeline being too aggressive for other reasons… so if your goal is to sort all this out today then I’m afraid this idea will probably not do that.

My expectation is there be no more updates to PEPs after the coring start, and therefore no more discussions either. Questions were meant to be raised during the period between Oct 8-Nov15 so PEPs could be updated based on those questions and concerns.
People should be voting based on the PEP text, not based on what they read on email/discourse threads.
Therefore there would be no need to change their mind after voting.

We’re at ~20 hours until the proposed start of voting (November 16th, 2019 AoE)… so given that a decision or clarification on voting procedures would be best sooner than later.

In the interest of keeping options open… I implemented an example Google Form based ballot here: https://docs.google.com/forms/d/e/1FAIpQLSfAirlEiM13PU-udTrGq1QX-u9jZqGZ5NvMUfNmm6IRdiXoIw/viewform?usp=pp_url&entry.321479192=deadbeef-dead-beef-dead-beefdeadbeef

The links can be supplied with unique Ballot IDs generated for each voter in their invitation to participate. Or the Ballot ID can be provided in the email and left to the voter to supply.

The biggest caveats I can see to a Google Form based vote:

  • Clearly it relies on additional trust in me
  • Returning to edit responses requires the user to copy/save the edit link explicitly
  • Limiting to a single response requires Google Sign-In, thus to make this as accessible as possible it would require me deduplicating potential additional responses based on “last vote”
  • Overall it reduces audit capabilities that the CIVS system provide

I don’t want to throw a wrench in anything, but do want the committers to know I’m prepared to administer the election in whatever way is decided.

Thank you @EWDurbin for jumping on this so quick. However, we cannot responsibly make such drastic changes last minute. Meaning, there are only two feasible options:

  • proceed as planned;
  • postpone the vote.

I am in the camp of people worried that postponing in the interest of “additional review and discussion time” is not going to achieve much (as the PEPs written in October had 6 weeks of review and discussion time on them). And there’s a price to postponing as this drags the process into new year [1]_.

I also can’t help but notice the irony of CIVS being used as the reason to postpone the vote by the group who pushed CIVS in the first place.

Nevermind though, the important thing here is whether the vote we’ll hold is going to be universally acknowledged as fair, inclusive, and binding. Looks like at least two PEP authors, as well as other prominent core developers, have doubts about this.

So really, should we postpone?
And if so, by how much?
And who gets to coordinate this? (I can but getting tired, my friends.)

Footnotes

… 1: The proponents of additional review and discussion time would probably not be happy with just a week for it, and we cannot hold the vote during Holiday season.

Since the chosen voting website doesn’t allow to change your vote, I would suggest to everybody to take their time during 2 weeks to read properly the 7 PEPs, exchange their opinion (ex: in Straw poll: Which governance proposals do you like best? thread), and only vote just before the deadline :slight_smile:

Or would you prefer to deny modifying PEPs anymore, have a 2 weeks period to review PEPs and discuss them, and 1 week to vote?

If it becomes very obvious just before the vote that we missed a better governance, it would still be time to cancel the vote. I’m not sure about allowing again to modify PEPs to take in account the feedback. It’s unclear if the feedback loop has a stop condition (Halting problem - Wikipedia) :slight_smile:

I’m thinking aloud to try to understand what you mean, but I am fine with the current PEP 8001 :slight_smile:

Certainly wasn’t proposing that we make a drastic change to 8001 at this junction. Just making clear it would be supportable.

1 Like

If someone thinks they may change their mind then they should wait until the end to cast their vote. I know of no other voting system (US elections, boards of directors, community ballots) that allows somebody to change their vote.

The time to make changes and join the development discussion is now past. Whether through lack of interest, lack of time, or unworkability of Discourse, the PEPs are done (or should be) and any further discussion needs to be why we like or don’t like them, not about changing them.

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