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

[Nathaniel Smith]

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