Just want to reiterate before I respond: it's totally fine if our decision is "we don't actually need a PyPA-specific governance process", but I do think there's value in having our own process.
Beyond that, my only objection to the doc is its characterisation of the current PEP process as being inaccessible: following the migration to GitHub last year, the existing PEP-based process is *exactly the same* as the process being proposed from a mechanical perspective, just with a different GitHub repo backing it, and with the "Discussions-To: distutils-sig" being implied by the choice of repo to submit the PR against.
As (I think) the most recent person to write a packaging-related PEP, as well as a first-time PEP author, I disagree with this based on my personal experience.
I think the PEP process is too heavy for the small and incremental changes we often need to make in the Packaging ecosystem.
For example, when I first wrote PEP 566, I really was only interested in defining a new metadata version which adds the `Description-Content-Type` field. However, since packaging PEPs are relatively infrequent, and require a not-insignificant amount of work to put together, a lot of other "planned but not yet approved" changes which were unrelated got shoe-horned into the same PEP, such as:
* The `Provides-Extra` field: https://www.python.org/dev/peps/pep-0566/#provides-extra-optional-multiple-u... * Changes to version specifiers: https://www.python.org/dev/peps/pep-0566/#version-specifiers * JSON-compatible metadata: https://www.python.org/dev/peps/pep-0566/#json-compatible-metadata
Adding the `Provides-Extra` field to the specification added to the work I had to do to implement the PEP, since I also needed to implement support for this field anywhere I wanted to fully support the new metadata version.
I was pretty motivated to make this change, so I was happy to take the extra work on. However I think that simply the existence of so many small changes that were "pending PEP" is proof that the PEP process and the way the PyPA currently uses it makes it somewhat inaccessible to make these small yet meaningful changes -- otherwise, they wouldn't have been "pending PEP".
Had the proposed process been in place, each of these changes could have been their own RFC, authored by the people who actually wanted them, and could have been accepted long I came around to make the `Description-Content-Type` changes.
D.
On Sat, Aug 18, 2018 at 12:30 AM Nick Coghlan ncoghlan@gmail.com wrote:
On Fri, 10 Aug 2018 at 03:33, Dustin Ingram di@python.org wrote:
I've made some updates to the document, generally accepting Donald's proposed changes here (with some minor tweaks to the wording), namely:
- No BDFRN role as ultimate arbiter
- Instead, nominated Interest Area Authorities for various areas of
interest under the PyPA, who act as the decision-makers instead of a given proposal being put to a vote
- Fallback on a vote if there is no Interest Area Authority or they
are otherwise unavailable
This thread has touched on a few different areas, so I'm just going to chime in here with a few notes of potential interest:
- While it was never especially well advertised,
https://www.pypa.io/en/latest/specifications/ is the page where I kept track of how we/I had adapted the PEP process to work better for PyPA's purposes. I agree with Donald that it was a workaround though, and it may be desirable to split packaging-only PEPs out to their own process (which can also be used for PyPA governance question), and only use the PEP process for actual standard library changes (such as switching to having setuptools provide the reference implementation of the distutils API, rather than CPython: https://github.com/pypa/packaging-problems/issues/127) 2. https://github.com/pypa/pypa.io/pull/34/files tweaked the current process to account for Guido stepping down as BDFL (the reliance on a BDFL had already been substantially reduced when I transferred my previous responsibilities to Paul) 3. https://github.com/pypa/python-packaging-user-guide/pull/547 finally added the missing link from the active specifications page back to the spec process management page
Beyond that, my only objection to the doc is its characterisation of the current PEP process as being inaccessible: following the migration to GitHub last year, the existing PEP-based process is *exactly the same* as the process being proposed from a mechanical perspective, just with a different GitHub repo backing it, and with the "Discussions-To: distutils-sig" being implied by the choice of repo to submit the PR against.
The key downsides of moving to a PyPA-only repo are that:
- we're going to have to find a new set of volunteers to serve as
PyPA RFC editors and repo maintainers (rather than being able to share the existing pool of PEP editors); 2. the PyPA process becomes less accessible to the Python community at large, since we're no longer sharing the same process and tools as the reference interpreter implementation (Rust don't have a separate process for cargo, for example - all the core tools use the same system at https://github.com/rust-lang/rfcs )
The main potential benefit I see is one Donald noted earlier in the thread: for folks interested specifically in Python packaging, and not language level questions, PEP 0 doesn't currently take the "Discussions-To" header into account, so the packaging PEPs can be hard to find. That said, I'm also one of the PEP 0/1 maintainers, and I'd be completely open to the idea of enhancing PEP 0 to better expose that categorisation information, as well as potentially amending PEP 1 itself to reframe the "Discussions-To" header as a "Topic Area" or "Interest Area" (and then link the venues to the topics, rather than the other way around).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia