Um, in a packaging context, there’s a standing BDFL-delegation (to me for interop and to @dstufft for warehouse). That’s the BDFL-delegate I’m talking about (and probably the one assumed elsewhere in this discussion). Agreed that assigning a further delegation would happen much later in the process.
… and that’s the part of the sponsor role that I think is enough of a commitment that it should only ever be voluntary. (And in the context of the comment above about what we mean by BDFL-delegate, I’m personally not willing to be sponsor-by-default for all packaging PEPs, for precisely this reason).
I’m willing to say that this is intentionally out of scope for this PEP since it’s a change over status quo – we’re just operating since we’ve got just-enough core-dev + PyPA members for this to not be a problem.
If y’all want to discuss this further, let’s discuss over on Should PyPA opt out of the PEP process? (which I’d explicitly requested to be split out because it’s a change in how we operate vs documenting how we operate).
The additional text I proposed was aiming to document the status quo, as is the case for the rest of the PEP.
It’s certainly not intended to require that the standing delegates sponsor PEPs that they believe aren’t ready for submission, just have them serve as the default entry in cases where what they’re saying is “I don’t believe this PEP author actually needs mentoring, and I’m happy to be the nominal sponsor on that basis”.
That was added to handle the case of experienced python-dev and python-ideas contributors that understand the PEP process well but aren’t themselves core developers, but it could be applied to PyPA and packaging PEPs as well.
Just an FYI, per Closing the loop on PyPA Governance / BDFRN the purpose of the BDFRN role was to create a formal governance process. Once PEP 609 is accepted, I don’t see a reason for this role to continue to exist.
One thing that’s very on-point for this PEP is whether we want to document how we’re handling PEP sponsors today.
If no one is opposed to it, I’m gonna file a PR adding language similar to the following, to the “Specifications” section:
As documented in PEP 1, PEPs that are not proposed by CPython Core Developers require a sponsor. It is expected that there would be CPython Core Developers within the PyPA community who would sponsor PEPs for the interoperability standards, when authors are not CPython Core Developers.
This change is separate from the “opt-out” discussion happening since I’m, personally, scoping this PEP to document status quo / change things we definitely have consensus on.
The status quo is really that additional sponsors can be listed in the standing delegation document alongside the standing BDFL-Delegates. Those standing delegates would also be eligible to sponsor PEPs.
PEP 1 already allows for that, there’s just a practical requirement to have a clear list of folks that the Steering Council have agreed are familiar enough with the PEP process to make good sponsors.
Dustin, I am in favor of this PEP, especially because it creates a reasonably lightweight procedure to accept new projects into the PyPA, and clarifies how individual membership works. I think accepting this PEP would help short-circuit a lot of frustration and confusion on that front.
I would like for us to finish and accept PEP 609, so that we can use it as a foundation for the next steps in governance – I hope that those next steps can help clear up confusions and unanswered questions that have gotten in my way as I’ve worked on Warehouse, pip, and other PyPA projects. @pf_moore and @dustin: as far as you can tell, are we just waiting on @pradyunsg’s PR regarding the Specifications section, or is there anything else we’re waiting for?
The latter is relevant since we should provide the context/history relevant to this PEP to the SC. This PEP and that discussions are two very-close-knotted-together topics (should PyPA use the PEP process / how should PyPA use the PEP process).
I notice that the Packaging-WG is part of the terminology section, but is not referenced anywhere else in the document. Perhaps drop this or add a note to clarify that there is not currently any formal relationship between these entities.
I’d suggest that as part of this PEP, the PyPA move from its own Code of Conduct to the PSF Code of Conduct. This likely requires the approval of the PSF Conduct Working Group, but it would allow for any incidents to be addressed by that group, rather than being in the hands of the PyPA.
I see nothing in the current draft that concerns me. I believe any formalization is well worth the effort to get things moving. As the PyPA organizes a bit more, it would be good to discuss what fundraising by the Packaging WG looks like and what requirements there would be for disbursement of those funds to the PyPA… but that doesn’t need to be codified into the governance doc.