PEP 772: A round of updates #4320
Conversation
Certain lines were wrapped incorrectly.
Instead of "expected", make it clear that the Steering Council "will" change their delegations.
There is a potential CoI around direct control over the funding that they would have approval power on.
This list needs to be written down before the PEP can be voted on / approved.
They might not want to become a voting member, or be appropriately available to do so.
| * Wider community members: An initial set of for-profit companies, nonprofit | ||
| organizations, academic or educational institutions and smaller unaffiliated | ||
| projects would be invited to nominate three individuals to represent them. | ||
| [TODO: add a link here for the initial set, that the authors curate] |
There was a problem hiding this comment.
This is intentionally left as a TODO.
There was a problem hiding this comment.
For history/archival reasons, can we have the eventual full list in the PEP itself, rather than an external resource?
| among the candidates, or else the winner will be chosen at random. | ||
| * Phase 1: A voting member (defined later in this document) can self-nominate | ||
| themselves for the council elections. Such a nomination must include | ||
| information about the member's relevant affiliations. |
There was a problem hiding this comment.
We don't say anything about non-self-nominations, but maybe we should allow voting members to also nominate other people, whether those nominees are themselves voting members or not (similar to how the SC and core dev nominations work).
| The Python Steering Council will delegate decision making to the Packaging | ||
| Council for PEPs related to the Python packaging. The bodies would work | ||
| together on issues that intersect the packaging domain and language stewardship | ||
| (including the CPython implementation, standard library, and distribution). |
There was a problem hiding this comment.
We've seen two such PEPs recently (776 & 780). Would it make sense to recommend something like a joint PEP delegate? Clearly not to be mandated, but it may help alleviate coordination delays between the packaging and steering councils.
There was a problem hiding this comment.
Interesting examples @AA-Turner!
Would it make sense to recommend something like a joint PEP delegate?
Could you elaborate? Who would do the delegation (presumably, the SC) and who would be the delegate (not the SC and PC together, right? Seems weird that the SC would delegate to itself).
There was a problem hiding this comment.
The idea is to reduce co-ordination friction between the two bodies. Taking two extremes:
- Each body considers only aspects within its own remit. Pros: no requirement for coordination, perhaps faster decisions. Cons: the decisions could differ (one rejects & one acceps), no consideration of overlap, decisions could be on different timelines, discussion could fracture.
- Both bodies consider the PEP together. Pros: consistency of position, one decision. Cons: likely to take longer to corral ten people, takes up time for both committees, slower pace of innovation.
My proposal instead is for the PEP to recommend that both bodies agree an individual/set of individuals to serve as the PEP delegate for each 'joint PEP', perhaps a nominated member from each committee, perhaps a domain expert, etc. This aligns with the mandate in PEP 13 "Instead of ruling on individual PEPs, it’s better to define a standard process for PEP decision making", and I would argue is more productive than the alternatives above.
Regardless of if you take my idea, though, I think it would be useful to add more detail on how 'joint PEPs' are decided. Currently it says "will work together", but this is vague. For example, what happens in the accept/reject scenario above, does one body have 'more' authority than the other, etc. There is no bright line between the language & its packaging, so there will inevitably be overlap!
A
| The Python Steering Council will delegate decision making to the Packaging | ||
| Council for PEPs related to the Python packaging. The bodies would work | ||
| together on issues that intersect the packaging domain and language stewardship | ||
| (including the CPython implementation, standard library, and distribution). | ||
|
|
||
| The PSF Board is encouraged to formally deprecate the Packaging Workgroup and |
There was a problem hiding this comment.
"close" or "end" instead of "deprecate"?
There was a problem hiding this comment.
Or "deactivate"? Following the language of https://www.python.org/psf/workgroups/
There was a problem hiding this comment.
Agreed that "deprecate" doesn't have the finality and closure I think we expect. @hugovk I'd be fine with "deactivate" although I can't find that word used at the workgroups link.
There was a problem hiding this comment.
Yeah, no "deactivate" at the link, but it has a list of "Active Work Groups" and "Inactive Committees & Work Groups".
| * Wider community members: An initial set of for-profit companies, nonprofit | ||
| organizations, academic or educational institutions and smaller unaffiliated | ||
| projects would be invited to nominate three individuals to represent them. | ||
| [TODO: add a link here for the initial set, that the authors curate] |
There was a problem hiding this comment.
For history/archival reasons, can we have the eventual full list in the PEP itself, rather than an external resource?
| The Python Steering Council will delegate decision making to the Packaging | ||
| Council for PEPs related to the Python packaging. The bodies would work | ||
| together on issues that intersect the packaging domain and language stewardship | ||
| (including the CPython implementation, standard library, and distribution). | ||
|
|
||
| The PSF Board is encouraged to formally deprecate the Packaging Workgroup and |
There was a problem hiding this comment.
Or "deactivate"? Following the language of https://www.python.org/psf/workgroups/
Co-authored-by: Adam Turner <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Adam Turner <[email protected]>
This will be best reviewed commit-by-commit.
📚 Documentation preview 📚: https://pep-previews--4320.org.readthedocs.build/