On Sun, Nov 18, 2018 at 3:17 AM Antoine Pitrou <anto...@python.org> wrote: > A couple days ago Nathaniel pushed significant changes to his governance > PEP (PEP 8016). This means some governance PEPs are apparently still > *not* finalized. This raises a problem: when can we consider that we > are reading the final version of a proposal (barring wording fixes or > improvements), not some work in progress draft?
There were several PEPs that received significant changes in the week before Nov 16 when the "review period" started (at least 8001, 8014, 8015, 8016), but AFAICT none of the PEPs have had any changes since then. > Not everyone keeps an eye daily on PEP changes and discussions. It > would be nice to be able to make one's mind at an idle pace. But that > requires that PEP authors don't make last-minute changes in an attempt > to gather more support. Thanks for raising this. It's an important issue and one where I've been struggling too. I'll put my conclusion first. My suggestion: - We do allow changes to the PEPs until the actual voting starts, but not afterwards - We leave it up to the PEP authors' judgement what changes they want to make - The PEP authors will work together to maintain a single shared changelog summarizing every change that's made to the PEPs after Nov. 16, no matter how trivial, and including links to the relevant commits so you can easily see the actual text - We'll include a link to this changelog prominently in the voting instructions etc. This is easy to implement, avoids messy subjective judgements about which changes are "too big", allows the PEPs to be tweaked and clarified through the review period, and would mean that so long as you read the PEPs at least once during the review period and then check the changelog before voting, you're guaranteed that you won't miss anything. Here's my reasoning: You're absolutely right, it's crucial that everyone know what they're voting on; that's basic to having a valid vote. (And I almost got bitten by this too – PEP 8014 changed a lot on Nov. 9, and it was only by random chance that I noticed it a week later!) But... right now people are still reading the proposals for the first time and requesting changes. And if someone's suggestion would be an actual improvement, and we turn it down because it's too late – that's disenfranchising in a different way, and also, like, deliberately choosing to make our governance worse than necessary, which is sub-optimal. Obviously once the vote starts we *can't* change the PEPs, because that would retroactively change the meaning of votes that were already cast. But until then, freezing and not freezing both make me really uncomfortable. It would be good if we could find a third way. To make this concrete, here are some examples of things people have brought up re: PEP 8016 since Nov. 16, where I'm not sure what we should do: - Xiang Zhang noticed [1] that PEP 8016 uses a piece of nonstandard terminology: "strict majority" where it means "simple majority". Oops. I feel like fixing this is probably a good idea, and as uncontroversial as any change could be? But OTOH if we don't have a changelog then even trivial changes like this might make you and others uncomfortable (they make me uncomfortable!), because without seeing the change we have no way to judge for ourselves how trivial it actually is. - Xiang Zhang and Victor Stinner are arguing [1, 2] for changing PEP 8016 to effectively require a slightly higher threshold for the steering council to block a new core developer for misconduct (4-out-of-5 instead of 3-out-of-5, see [3] for the details). This is a small tweak in a corner of the proposal we hope will never come up in practice, and it definitely wouldn't change the proposal's overall character, but it is a change. It would produce some procedural simplifications, and apparently make at least two core devs more comfortable. Is that something we should do? - Steve Dower has suggested [4] tweaking when in the release cycle the steering council election is held. This discussion isn't resolved yet, maybe we'll conclude it's a bad idea anyway, but OTOH maybe it would be an improvement? And again it's a super-tiny change. It's possible PEP 8016 is particularly prone to this because a design goal was to be small and explicit enough to encourage <del>nitpicking</del>detailed review, but I'm not just suggesting this because "my" PEP has special needs. Other potential changes I'm aware of: - Steve Dower is considering withdrawing PEP 8014 entirely [4], which if it happens would be a major substantive change to PEP 8014 that voters would want to know about! - In the course of a discussion that Paul Moore started about processes for promoting core devs, I realized [5] that there's (what feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about how much power the Technical Leader or Trio would actually have – specifically I'd been assuming one thing, but realized that the texts actually don't say either way. I hope Barry and Mariatta will clarify what they intended before the vote starts. No matter which way they clarify things, it may feel like a substantive change to some people, depending on how they read it originally. In this last case, I *guess* as the co-author of a competing PEP I could be like "haha, PEP 8001 says it's too late for substantive changes so your PEP loses", and then they could be like "no these changes aren't substantive because we're just clarifying what we meant all along", and then I could be like "well as a voter it feels substantive to *me*"... but this sounds like a miserable way to live. I'd really rather Barry and Mariatta have the chance to clarify their PEPs before the vote, so that we all know what our options are and that those options are the best they can be, and that we skip any pointless arguments about it. The changelog approach is simple, unambiguous, easily enforceable, allows the PEPs to be clarified, avoids intrinsically subjective arguments about what counts as "substantive", and makes it easy for Antoine to know exactly what he's voting on instead of having to trust that everyone else's definition of "minor tweak" matches his own. -n [1] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/36 [2] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/37 [3] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/35 [4] https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/51 [5] https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436/25 -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
