PEP 609: PyPA Governance

Continuing the discussion from https://discuss.python.org/t/closing-the-loop-on-pypa-governance-bdfrn/, there is now a draft PEP:

2 Likes

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:

  1. Confirming that a proposal is sound and ready for submission as a PEP
  2. 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 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