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

[Paul Moore]

On Mon, 19 Nov 2018 at 11:24, Nathaniel Smith <njs at pobox.com> wrote:
> 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.

I agree, this is a really difficult question to get right.

My feeling, however, is that the PEPs that are having the most trouble
with this are the ones that are trying to pin down too much detail.
Sure (to pick a random example), it's ultimately going to be important
that a council have a clear idea of how they reach agreement on
banning a core developer, should that situation come up. But is it
really going to be so critical to establish that detail *right now*
that someone would change their vote **to a completely different
governance model** if the number of votes was set at 3 or 4? And is
the proposal explicitly denying us the chance to change that number
based on experience going forward?[1]

I realise this is precisely the point you made about subjective
judgements, but I think it needs to be taken in context. I have a
maximum of 7 proposals to choose from (6 if Steve withdraws his). I'm
interested in the overall "shape" of the proposal (leader or group who
decides vs community voting for example) and the "tone" (is it
concerned with pinning down lots of details, does it assume we'll
trust each other to work in good faith, is it bureaucratic, is it
well-established or novel, etc). The sorts of changes you're talking
about in the examples you give mostly leave me with a feeling of "this
proposal is prone to getting bogged down in details, it's
overspecified", and that's what will affect my vote rather than the
actual detail being debated[2].

> 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.

I'd characterise this more as "PEPs that try to specify too much
detail are prone to this because they encourage 'detailed review'"...
;-)

> - 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!

Knowing about it - definitely. But more importantly, I'd like to know
*why*! If Steve no longer considers his proposal worth voting for,
what is his logic, and what does he consider a reasonable alternative
for people who *did* want to vote for it? Personally, I'm not that
worried as that wasn't one of my preferred proposals, but I do think
that if you have created a proposal, you have a certain level of
responsibility to the people who liked it to give them information on
what you view as the "migration path" from what they voted for to
where you are now (and "not being able to vote for it" is a pretty
extreme case of that!)

> - 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.

And yet, I hope they don't, as a key point for me about their
proposals is that they *don't* try to specify everything up front, but
rather they allow for the leader/council to make judgements as time
goes on. If you feel that as a result their proposals are
underspecified, by all means vote for something else.

> 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.

So is forming an opinion by viewing the proposals, and then hoping
that no-one publishes a rewrite that means you have to rethink your
position at the last minute. It doesn't really help that you have a
way of being notified about major changes, the point is that we don't
want them to *happen*. (Yes, "major" is subjective once again, I
know.)

> 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.

Assuming that we'll deal with things when they happen is also an
option, IMO. I'd prefer it if we didn't reach a point where no
proposal offered that option. And frankly, changing from a relatively
underspecified position of "give some people authority, and let them
make the decisions" approach to one more like "elect a
group/individual to implement the set of rules we state here" is
*definitely* a substantive change, so one I'd oppose allowing now that
the review period has started.

> 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.

... but means that in theory, *anything* could change right up to the
start of the voting period, which makes the introduction of an
explicit review period pointless - we could just as easily have
started the voting period on the 16th in that case.

[1] It's possible that it *is* that important for some proposals. That
says to me that those proposals don't have enough built in flexibility
to react to unexpected situations (e.g., they have no mechanism for
deciding on a decision making system for an unanticipated event).
[2] And yes, that does mean that I'm currently inclined towards
particular governance models based more on how they are presented,
rather than on how they are structured. I'm not going to apologise for
that, or even accept that it's wrong. Any system can work if it's
implemented in a sufficiently flexible and sympathetic manner,
conversely any system can fail if it gets bogged down in bureaucracy
and over dependence on rule-book solutions.

Paul

PS I wrote this without going back over the PEPs, apologies if I've
misremembered or misrepresented anyone's proposal as a result of that.
PPS It's quite possible that my comments here aren't 100% consistent
with what I've previously written. I'm still forming my opinions and
they are changing over time - as well as not being super-precise in
the first place (I'm judging a lot of this on "gut instinct" that I
can't always put into words). So apologies for that as well.