I maintain a Version History in my PEP 8015: https://www.python.org/dev/peps/pep-8015/#version-history
Victor Le lun. 19 nov. 2018 à 12:24, Nathaniel Smith <n...@pobox.com> a écrit : > > 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/ _______________________________________________ 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/
