Last night @dstufft and I were both reading through the proposed governance PEPs. When we compared notes, we discovered that we both felt like there was a proposal missing – and it turned out to be the same proposal!
Here’s what we’re thinking: this poorly-defined process we’re going through right now, where no-one knows what’s going on and we have to somehow get consensus between dozens of core devs – it sucks. We would like to avoid doing it again.
Why might we find ourselves having to do it again? One risk is that we adopt a proposal that turns out to be missing crucial details that need to be filled in later. (We feel like a this is a non-trivial risk
with several of the existing proposals that we otherwise like.) Another risk is that after adopting some proposal, we discover it isn’t working the way we want, and needs to be changed. In fact this
seems inevitable to some extent – we’re surely going to want to fine-tune things as we go. And while we’re intrigued by some of the more experimental proposals – maybe they’ll work great! – being the
first project to try a new governance model is inherently risky.
How can we minimize these risks?
Our idea is to have a minimalist model that defines a core “steering council” or “oversight committee” or whatever you want to call it. They’d have broad authority on paper, but the expectation is that in
practice their main purpose would be to ratify more detailed workflow PEPs, handle bureaucratic necessities, etc. And if some unexpected situation arises where we need an ad-hoc decision then they will, but their goal should be to minimize that as much as possible. So… think of them as a kind of governance-sig, that can generate formal decisions when formal decisions are necessary, and other core devs don’t have to get involved unless they want to. Or for our US readers, the idea is: we don’t need to define all the laws at this point, we just need a constitution.
This minimizes the risks because:
- There are lots of major projects that use this kind of mostly-hands-off steering council model (e.g., Django, NumPy, Node.JS, …), so it’s “boring”, in the good way that mature technology is boring.
- By narrowing our scope like this, it becomes easier to be really rigorous in defining the details, so we can have more confidence we haven’t missed anything important.
- By deferring governance details to later, we keep the flexibility to fine-tune processes and experiment with new decision-making workflows without having to go through this process again. (For example: if we want to try out PEP 8013, the steering council could start by
appointing an auditor to handle a single PEP, and see how it goes.)
What’s this thread then? where’s the PEP text?
That’s the basic idea. But of course there’s a bunch of details to work out. And since we know a lot of people want to get all this settled ASAP, our plan is to get a complete draft submitted to the
PEPs repo by the end of tomorrow (Thursday). But we haven’t written it yet.
I guess the traditional thing would be to go off in private and write it all up and present it as a finished work, but we figured it can only help to get more feedback / discussion as early as possible. So
instead of a private chat we’re going to use this thread to do the writing instead. Feel free to jump in! Co-authors welcome! Let’s see if this Discourse thing works as well as advertised!
Okay so what will the PEP actually look like?
- The process for electing the steering council
- The process for people joining/leaving the core team
- The process for changing the constitution
This seems like the Minimal Viable Governance to me – everything on that list is necessary. (The steering council election process says that core team members are the electorate, so in order to define one you have to define the other.)
So to keep this simple and as boring as possible, I’m thinking we’ll steal text and details from that Django document wholesale, except where we have specific reason not to.
My initial to-do list for things I’d like to discuss beyond that:
- CPython-specific language about the steering council’s mandate (e.g.: formalize and maintain relationship with PSF; try to make Python development process humane and sustainable, and reflective of Python’s diversity of use cases and users; serve as a “court of last
resort” for technical decisions when all else fails; …)
- A written-down process for handling unexpected vacancies on the steering council, both for the obvious reason (life happens) and to reassure members that if they need to step down then it won’t cause a disaster.
- Maybe some rule to avoid the appearance of conflicts of interest, e.g. no more than 2-out-of-the-5 members can share an employer?
- I liked some of the language in PEP 8011, like this
and this, maybe we should steal some of that too.
- Donald wants to talk about recall procedures (may be more relevant for us than for Django, since Django’s terms are super-short – 8 months, if I’m reading it right).
Maybe we should make an etherpad or google doc or something to use as
a working document?