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.
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.
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.
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?
Once @pradyunsg has made any pending changes, I think this is not waiting on anything else.
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).
I’ve gone ahead and:
- filed a PR for the changes mentioned earlier: https://github.com/python/peps/pull/1425
- Noted on Should PyPA opt out of the PEP process? that I won’t be able to work on writing the required summary in the near future, and welcome others to take that forward.
Discourse is telling me:
Let others join the conversation
This topic is clearly important to you – you’ve posted more than 20% of the replies here.
So, I’ll shush now and go make dinner.
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.
Adding the clarification note sounds like a plan! ^>^
See Move to the PSF Code of Conduct? and know I’m actively working on it. Happy to see it in the PEP explicitly, though.
Thanks @pradyunsg for your pull request to clarify how the standing delegations interact with PEP sponsorship/approval. Once we get that reviewed and merged:
I submitted https://github.com/python/peps/pull/1434 to do this. Awaiting review.
I suggest we either
- have Dustin (as BDFRN) prnounce that “yes, we’re now under the PSF CoC”, and then add that to the PEP & other PyPA docs
- get PEP 609 in place first, and then use its committer vote mechanism to get a clear ratification of the CoC change.
My sense of @dustin is that he would prefer the latter. Tell me if I’m wrong! Or if there’s another option I missed.
I think a 3rd option (and my preferred option) would be “just put it in the PEP, as part of the new governance process, and have the acceptance of the PEP make it official.”
@dustin Here’s a pull request to add the new PSF CoC stuff to the PEP; please review.