[python-committers] A different way to focus discussions

[Nathaniel Smith]

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