[python-committers] A plea to stop last-minute changes to governance PEPs
Nathaniel Smith
njs at pobox.com
Tue Nov 20 02:46:43 EST 2018
On Mon, Nov 19, 2018 at 5:30 AM Paul Moore <p.f.moore at gmail.com> wrote:
> 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]
PEP 8016 does try to specify all the details needed to get us out of
our current state of ambiguity, so that if we adopt it then we're
ready to go immediately and never have to go back to our current
ill-defined process. That forces it to specify various details, but
beyond that it tries to specify as little as possible (so lots of
details are delegated to the future governance system, rather than
being resolved right now), and for the things that it does specify, it
also specifies how we can change them:
https://www.python.org/dev/peps/pep-8016/#changing-this-document . So
we can totally change things going forward.
If the PEP left blank spaces to be filled in later, then when would we
fill them in, and how? Are you imagining we'd have a second round of
voting to fill in the details, or what are you thinking?
> I realise this is precisely the point you made about subjectivea way to change those details – see
> 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].
Well, that's up to you I guess :-). None of the bureaucratic details
in PEP 8016 have anything to do with day-to-day development, and for
uncontroversial decisions, governance doesn't matter at all. The only
time a governance PEP matters is when we hit an ambiguous situation
where people are disagreeing. IMO that means the governance probably
shouldn't leave the details ambiguous and assume people will agree on
how to handle them :-).
But that's kind of neither here nor there... even if you disagree with
me about that, I hope we can still agree on one thing:
> > - 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.
If you're right that Barry's intent for PEP 8010 is to make it a kind
of "template" for a future governance PEP, with details intentionally
left underspecified to be filled in later by some yet-to-be-determined
process, then it would still be helpful for him to specify *that*.
That would give us both the information we need to vote :-).
-n
--
Nathaniel J. Smith -- https://vorpus.org
More information about the python-committers
mailing list