Continuing the discussion from https://discuss.python.org/t/closing-the-loop-on-pypa-governance-bdfrn/, there is now a draft PEP:
Thanks for moving this forward.
In the section on Specifications, I think it would make sense to cover the PEP Sponsor aspect explicitly, with a sentence/paragraph along the lines of:
To cover the PEP Sponsor requirement, there are several PyPA members that are also Python core developers. In the absence of another sponsor, the standing PyPA delegate for a PEP will act as the sponsor.
It’s not immediately clear to me what this means. Does this mean that as a packaging PEP author, if I can’t find a sponsor, the BDFL-Delegate must be the sponsor (even if they don’t want to be)?
That seems against the spirit of PEP 1. As I understand it, the point of getting a sponsor is to ensure that low-quality or otherwise unsuitable PEPs don’t get submitted, to reduce the burden on the PEP editors (and others involved in the PEP process). So persuading someone to be a sponsor is absolutely part of the point here, and mandating that the BDFL-delegate (or anyone else!) must be the sponsor if no-one else can be found defeats that object.
Having said that, PEP 1 says:
The sponsor’s job is to provide guidance to the PEP author to help them through the logistics of the PEP process (somewhat acting like a mentor).
That’s where I feel there’s a difficulty. PEP sponsorship, while not a huge task, is nevertheless a commitment, and I don’t think it’s reasonable to require anyone to take on that commitment if they don’t want to.
In my view, the two aspects of sponsorship:
- Confirming that a proposal is sound and ready for submission as a PEP
- Guiding the proposer through the PEP process
are distinct roles. The BDFL-Delegate can do the former if no-one else is available (that’s just an extension of the BDFL-Delegate role to encompass a preliminary review), but I think that either the PEP author should be expected to find someone to help with (2), or we shouldn’t require that - I’m not sure how important it is, particularly for people involved with the process already. Maybe we could make the “get a mentor” aspect optional?
If you’re ready to assign the BDFL-Delegate that early on then they could handle the mentorship aspect as well, but that is somewhat the opposite time frame for find a BDFL-Delegate. You usually want someone who is going to be impartial and ready to judge the PEP as it stands, so you typically don’t want someone who is so enthusiastic about an idea that they are going to help the PEP through the process. Otherwise they basically are a sponsor or co-author.
It’s been very helpful in shutting down bad ideas early on. It also means that as a PEP editor I don’t have to proof anything for new PEPs anymore as I get to rely on the sponsors to make sure that the PEP is good enough to be ready for checking in (and since sponsors are core devs they can do the initial check-in themselves).
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”.
I’ll also note that PEP 1 was fairly recently updated to allow for PEP sponsors that aren’t core developers: https://www.python.org/dev/peps/pep-0001/#submitting-a-pep
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.
Dustin (and any future BDFRN) is the main case where I think it would make sense to ask for that (probably as an addition to the standing delegation document at https://github.com/python/steering-council/blob/master/process/standing-delegations.md), but that would be a change from the status quo, so it wouldn’t make sense to include it in the initial iteration of this document.
Just an FYI, per Closing the loop on PyPA Governance / BDFRN - #38 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.
A valid point! While I’d still suggest that we aim for a system where you can sponsor your own PEPs, Pradyun is right that that’s a discussion for the other thread.
1 Like
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.
1 Like
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.
1 Like
Ah, indeed. Thanks for catching that @ncoghlan! 
I’ll try to come up with words for this and file a PR to the PEPs repository for this.
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 just created this PR to update pypa.io with some lightweight explanation of how project & individual membership currently works; am taking a few days to wait for reviews, then will self-merge if no one objects.
1 Like
See also: Moving python-build to PyPA, which is asking whether an existing project can be added to the PyPA org.
OK, that PR is now merged and https://www.pypa.io/en/latest/members/ is now up.
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?
I agree.
One question - who does this go to for approval? I don’t think it is really within either my or @dstufft’s remit, so I assume it will have to be submitted to the Steering Council?
My understanding is that if there is no BDFL-Delegate, it goes to the Steering Council (to either decide or assign a BDFL-Delegate).
I think this is blocked on:
- a PR from me, as mentioned earlier in this thread/topic/discussion
- a summary of Should PyPA opt out of the PEP process? should either be added to the PEP or provided in the python/steering-council issue for this PEP.
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).