[python-committers] A plea to stop last-minute changes to governance PEPs

Mon Nov 19 06:37:09 EST 2018

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 <njs at pobox.com> a écrit :
>
> On Sun, Nov 18, 2018 at 3:17 AM Antoine Pitrou <antoine at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/