> On Aug 18, 2018, at 1: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:
>
> 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.

While I do think the PEP process has gotten *better*, I also do agree with Dustin it is more inaccessible than the proposed process. It might be more antagonistic than required though to call out the PEP process as inaccessible though (and opens up the question of if it’s inaccessible, why not fix it?). A larger reason for me is that by doing our own thing, we can better optimize the process to our personal needs, rather than having the PEP process serve two distinct groups. This is particularly note worthy with Guido stepping down, as python-dev is looking at what their process is going to be in the future, and AFAIK has not even considered the impact on us in their decision making— which is perfectly fine! It just underscores in my mind that we’d be better served by something dedicated to us, whose primary goal is making our decisions.

>
> 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);

I don’t think that we even need this really. As a set of text files it doesn’t really need “maintained” the same way software does. There’s no special parser or anything that comes with it like the PEP repository does. It’s just some text files in a repository, and Github handles the Markdown rendering for us.

Honestly, I don’t even think *Python* really needs this any more. It made a lot more sense when getting a PEP added to the repository and changes integrated meant emailing a patch, but with a PR based workflow whoever is accepting it can just hit the merge button. There’s not really a large need for some arbiter to sit there and garden the PEPs/RFCs.

The primary benefit they bring in 2018 I think is in assigning PEP numbers, the proposed process has the same bottle neck, rust works around it by just using the PR number as the RFC number, we might want to consider doing that by default as well.

> 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 )

I don’t think the community at large uses the PEP process or finds them more or less accessible to anything, because as far as they’re concerned they’re just convenient ways to specify some change that python-dev is making, and they don’t get involved in the process at all. I don’t think that the proposed process really changes much for them.

>
> 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