Now that PEP 8016 is accepted, I am worried that it doesn’t really specify at all how the process for dealing with PEPs is going to be. It only says that the new council should decide. In that sense, it seems to me that PEP 8016 is simply a way to postpone the real discussion on how to organize the PEP process. Do the PEP 8016 authors (@njs@dstufft) have proposals for that? If not, should we start discussing that right away, before the new council is elected?
I am asking as PEP 580 author who is waiting for a long time to finally get that PEP reviewed.
Ultimately all responsibility lands at the feet of the steering council. They are able to pronounce on PEPs if needed. The larger goal of PEP 8016 is to allow flexibility in that PEP process so that the steering council can amend that PEP process as desired, potentially by giving it an entirely new and different process.
So to answer your question, once we have a council, that council is free to pronounce on PEPs if they so desire. They’re also free to say that they don’t want to pronounce on a PEP until they’ve decided on changes to the PEP process.
No one can guarantee anything until the council is elected, but you can certainly make their job easier. If I were you, I’d start assembling evidence now that PEP 580 is uncontroversial and all the relevant experts think it’s ready to be accepted, so it’s ready for quick acceptance in February.
I assume that for most PEPs the only involvement of the council is to select a PEP-Delegate (formerly BDFL-Delegate).
I have a PEP for which I want to be that delegate – PEP 544, which specifies Protocols to be used by type checkers and their runtime support. It’s been implemented for a long time and there are a few small tweaks that need to be made, then I think it can be accepted.
