[python-committers] A different way to focus discussions (original) (raw)

Nathaniel Smith njs at pobox.com
Fri May 18 21:29:24 EDT 2018

On Fri, May 18, 2018 at 3:25 PM, Guido van Rossum <guido at python.org> wrote:

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

PEP 572 seems like something of a perfect storm... it's simultaneously a bikeshed and a nuclear power plant [1], and also the rare proposal that you like but that significant numbers of core devs find deeply objectionable; any one of these would tend to produce a lot of email, and then the combination is something else again. Is this proposal mostly responding to that, or something that you've been thinking for a while?

[1] For those unfamiliar with this example: https://en.wikipedia.org/wiki/Law_of_triviality#Examples

I wonder if it would make sense to require that for each PEP a new GitHub repo be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

To some extent this has been happening informally for a while. Just off the top of my head:

PEP 465: https://github.com/numpy/numpy/pull/4351 PEP 543: https://github.com/python-hyper/pep543/issues/2#issuecomment-309199376 PEP 513: https://github.com/pypa/manylinux#the-pep-itself A repo full of packaging PEPs: https://github.com/pypa/interoperability-peps

For a lot of us these days, putting a document in a repo is just the default way to work on it (and get feedback, etc.).

Managing the relationship between these repos and the main peps repo is currently pretty awkward. They tend to get out of sync in both directions – people make edits directly to the PEP repo – plus in general some pieces of information are in one place and some in another, there's no link between them, the original repo can get misplaced over time...

This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.

PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).

I'd be somewhat tempted to require people to use Github and to move the repo into the python/ organization when it gets a number, so that there's one canonical place to look for the history and we have some control over its lifecycle.

More radical idea: what if the PEPs index just linked to the Github rendering of each file? That's always going to be up to date, it comes with a link to the issue tracker at the top, it has a nice "Edit" button if someone wants to submit small fixes as a PR...

Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Rust's RFC process is a bit different, but may be of interest: https://github.com/rust-lang/rfcs

One thing people might worry about is missing out on discussion they're interested in – there wouldn't be one central place to subscribe to see discussions. Rust's concept of a "final comment period" is a nice way to manage this.

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the python-committers mailing list