On Fri, 10 Aug 2018 at 03:33, Dustin Ingram
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: 1. 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: 1. 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