[python-committers] A different way to focus discussions

[Gregory P. Smith]

On Fri, May 18, 2018 at 3:28 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. :-)
>
> 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.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/0a06bc03/attachment.html>