On Aug 8, 2018, at 12:25 PM, Paul Moore p.f.moore@gmail.com wrote:
On Wed, 8 Aug 2018 at 16:39, Dustin Ingram di@python.org wrote:
I should say: it's also fine if we just don't want a governance model because we think the existing process is fine.
I'm not averse to a governance model (caveat - I consider what we have right now to be a perfectly valid "governance model", it's just less formalised than the one you proposed), I just don't think it necessarily needs to apply to the interoperability PEP side of things (or rather, I don't think there's evidence that we need to *change* the governance model for that).
However, for those that weren't at PyCon this year, one of the outcomes from the packaging mini-summit was the idea that we _might_ need a governance model, hence this proposal.
As I wasn't there, I can't really comment on that. Did anyone present any reasons why what we currently have (for interoperability specs, specifically, as that's the *only* place I have a concern about what you propose) is insufficient, or is not working? I'm a great fan of "if it ain't broke, don't fix it", but that does mean we need to get feedback if people think it *is* broke :-)
So I’m a big fan of adding a more formalized governance model to the PyPA. I think it will help deal with some more community minded issues that we don’t really have a great person deciding for right now (for example, standardizing communication channels as best as we can!). This fracturing ends up hurting users because while it makes sense to us where the lines are drawn and what goes where, your average user might bounce between 2 or 3 different projects before figuring out where their problem actually lies. Trying to standardize those things as much as we reasonably can will only help every body.
When it comes to the interoperability specs, there are a few reason why I think we should pull them under the same process:
- Having two distinct processes, with basically the same people involved is kind of a drag. You can end up with grey areas where you’re not quite sure what process to follow for what. - The PEP process is really designed for changes to Python itself (and even more specifically, generally to CPython itself). While we’ve used it successfully, there are always these sort of weird square peg round hole situations that we’ve hit over the years. Some of them off the top of my head: - It’s actually pretty difficult to locate the packaging PEPs on PEP 0 unless you already know what they are or you just search for the last names of the usual suspects. - The fields and documentations for writing a PEP don’t really fit well, for example the “Type” for the PEP. We tend to bounce between the three types, because none of them are really a great fit. - Because the process itself is tied to what python-dev does, we’re beholden to the decisions there. While some of us (yourself, myself, Nick, etc) are also Python committers and thus have a say in that process, most of the PyPA members are not, and thus have no real say in the PEP process. - Baked into the *current* PEP process, is the idea of a BDFL, which has obviously historically been Guido. However our “power” (such as it is) never really came from Guido’s blessing, it came from the fact that we collectively develop the tooling that the vast bulk of people use to package, distribute, and install their Python projects. To put another way, inherent in the current PEP process is the idea that the BDFL of Python could tomorrow write a new PEP that says all version numbers are to be written in Roman numerals [1], and that puts us in a place where we have to start rejecting some PEPs in our tooling, while still using the process for other changes, and having to communicate to people which PEPs we ignore and which we don’t [2]. - Guido has taken a “permanent vacation”. That means what the PEP process becomes is totally up in the air right now. Technically speaking there is an argument to be made that no PEP can actually be decided on right now, because there is no BDFL (and in PEP land, the BDFL-Delegate’s power flows from the BDFL, with no BDFL there’s no BDFL-Delegate). Of course I doubt anyways is going to stop us from still using our current process, however what is the PEP process going to become? One of the options currently being discussed on python-committers is that all PEPs get decided by a vote of the core developers of CPython… which obviously doesn’t work for us. If that happens where does that leave us? Do we just further diverge from the “standard” PEP process and retain our BDFL-Delegates? Do we tack a “and for packaging stuff, pypa-committers votes not python-committers” into the PEP process? Even if we stick with a BDFL (or a council of BDFLs) whose to say those members aren’t going to be someone who has Guido’s hands off approach to packaging, and they won’t come and decide that they want to handle packaging PEPs themselves? [3].
That being said, one of the things I might suggest as a change to Dustin’s proposal is the idea of “areas of interest” or something like that. There are three possible ones off the top of my head that I can think of:
- Governance / Cross Project decision making - Interoperability Standards - PyPI
I think it wouldn’t be a bad idea to allow pypa-committers to basically elect someone to act as the BDFL of a particular area— effectively our own BDFL-Delegate system, but where the power flows from pypa-committers instead of python-committers/a hypothetical future BDFL. It’s unlikely (past the first round of this) that we’d ever elect a delegate for the Governance area of interest, but I think electing ones for the packaging standards, and PyPI would make sense. Dropping the idea of “FL” from this system, having it flow from the pypa-committers gives us an easy fallback for if the delegate for a particular area is unavailable for any reason (steps down, gets hit by a bus, whatever)— we would just fall back to voting by pypa-committers until that person is either available again, or a new delegate is elected.
If we went with that, I personally don’t see any reason why we wouldn’t elect to keep the same delegates we currently have (Paul Moore for Interoperability standards, Myself for PyPI) but of course, if it’s now an elected by pypa-committers position, those roles aren’t guaranteed either.
[1] Forgive me for the hyperbolically silly example! [2] This has of course always been true, but Guido didn’t really care to step into the packaging space, and we all knew/trusted his decision making anyways, so we knew he wasn’t going to do something like that. [3] This goes back to the idea that the PEP process isn’t our process, it’s CPython’s, and it’s currently got a big ? on what it’s going to look like in the future, and besides a handful of us, the PyPA developers don’t really have a say or input into that at all.