I am not sure if this is the right venue to discuss this, but since the original decision to leave decisions on the interoperability standards to the PEP process, a requirement was added that all PEPs originate from or be sponsored by a Python core dev, which means that even Dustin, the BDRFN of the PyPA, needs to get a core dev to sponsor this proposal, which rubs me the wrong way a bit.
Obviously it’s not a huge deal because there’s a good amount of overlap between PyPA and CPython core dev (I dunno who would self-identify as being “in the PyPA”, but there’s I think at least 7 or so Python core devs involved in the PyPA), but it does feel like an unfair asymmetry that I can propose packaging PEPs without a sponsor but Pradyun and Dustin (and many others) cannot. I think at the very least there needs to be a process by which PyPA members can be empowered to make these proposals without a sponsor: I am ambivalent as to whether that is automatic upon joining any PyPA project or whether there’s a slightly higher bar - but it cannot be as high as “is a core dev of CPython”.
Once we decide who we, as the PyPA, want to be able to propose interoperability specs, the ways forward I see are:
- Use essentially the same PEP process, but in a different namespace (e.g. PPEP - Python Packaging Enhancement Proposals) and with our preferred rules for who can propose them.
- Continue using PEPs, but get a ruling adding the PyPA’s “allowed list” to the list of people who can sponsor (at least) PyPA-related PEPs in the main namespace.
- Move to our own process (possibly one where decisions are made by people elected by the PyPA rather than by core devs).
I have listed them in order of desirability from my perspective. I think in the long run we may want to move to #3, because increasingly core dev and PyPA are two distinct groups with distinct needs, but in the short-to-medium term, taking advantage of the fact that the SC exists and is willing to decide on (or delegate decisions about) packaging topics to ease the transition from “loose collective” into “well-governed meta-project”. I favor a new namespace over the main namespace (#2) because I think it’s a better way to organize our proposals and because it makes a transition to something like #3 the easiest.