On Fri, May 18, 2018 at 3:28 PM Guido van Rossum <guido@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. :-)

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.

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.

overall I think this idea has merit.

flaws?  People who haven't yet given attention to the PEP over in its own world are likely to spawn the same threads on -ideas or -dev when the PEP is introduced there.

So long as something is public, there will always be outsiders. It also seems like using a forum such as a repository full of PRs threads can lose the discussion history as PRs are not a mailing list archive and can disappear at the whim of the corporation hosting them.  But do we care about that?  In theory all arguments and alternatives for/against are _supposed_ to be captured into the PEP doc itself before it is accepted.

I do like the ability to have a technical code discussion in markdown as PRs allow vs email.  But if there are 100 people chiming in, I doubt this would make anything any easier to follow.

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

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.

It sounds like your primary goals here are
 (a) to avoid PEP discussions on the -dev and -ideas mailing lists and
 (b) to have a central place for all discussions spawned from a specific PEP instead of trying to piece together 18 centithreads with varying subjects from python-* list archives.

I think (a) would happen at the start, and (b) would be true in this scenario so it is probably worth a try.

I do expect (a) to overflow to the mailing list anyways at times.  But this would give us the opportunity to redirect that away from the list.  It should still be better than the common mailing list free for all we have today.  It seems a bit more like a "working group" system. (which is what Carol's description of Jupyter incubator reminds me of)

*repos* where PEP discussions take place could optionally be CPython forks with an example implementation to eventually be used to construct the ultimate PRs adding it if the PEP is accepted.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)

I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.