[python-committers] A different way to focus discussions

[Paul Moore]

On 18 May 2018 at 23:25, 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. :-)

It's not scalable, certainly. But it's still (IMO) fine for all but
the larger PEPs - the trick is spotting which PEPs are "too big" :-)

I'm not sure that the issue with python-ideas is that bad. That list
is *designed* for incomplete and unformed proposals, and so long
threads are common (and accepted) on there. People on python-ideas are
used to skimming or ignoring/blocking threads they aren't interested
in. So by the time things are ready to go to python-dev (or wherever)
there's a good sense of whether the PEP is likely to be controversial.
I'd suggest that this is the point when the decision to go to
python-dev or github could be made.

> 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.
>
> 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 would prefer that PEP repos remain on github, and that once the PEP
is finalised (accepted, rejected, whatever) moved under the CPython
organisation (the whole repo, issue tracker, history, everything) so
that the history of discussion isn't lost. Current PEP discussions are
retained on the list archives, and I think the discussion history is
valuable (even if a lot of it ends up being noise at the moment). I'd
rather not have to maintain extra accounts for bitbucket or gitlab,
and learn how notifications and tracking work on those platforms. A
common interface is important. Adding barriers to contribution does
filter out casual commenters, but I'm sure we don't want to be seen to
be deliberately making it *hard* for outsiders to get involved.

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

(Later)
> I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)

Avoiding *discussion* is probably OK. But regular summaries of
progress would, I think, be critical. Otherwise python-dev is
essentially cut out of the loop, and this becomes more of a change in
governance, as Antoine mentioned.

I'm not quite sure what your intention was, but I'd like to see a
series of announcements on python-dev for a PEP which is being
discussed offline:

1. An initial announcement of the creation of the PEP repo, giving a
summary of the PEP (the abstract from the proposal), and a pointer to
where interested parties should go to participate in discussions.
2. Progress announcements, maybe once a month, repeating the summary
and adding a "what has changed" summary.
3. Preliminary announcement of the decision on the PEP (a "release
candidate" if you like) stating that the decision has been made, what
that decision is, and that it will be officially announced in (say) a
week.
4. Final announcement, giving the summary, the decision, and pointers
to the final PEP text and the discussion (now hosted permanently under
the cpython org on github).

The point of the "release candidate" stage is the same as the RC for a
release - last chance to raise showstopper problems, plus announcing
the start of the "release" work (moving the repo, specifically).

I'm not that wedded to the RC announcement, but it will avoid the
final decision coming as a complete surprise to python-dev. As a data
point, I currently have no idea whether the discussions on the binding
expression PEP are still just rumbling on, or whether a decision is
imminent. Of course, if the progress announcements are sufficiently
good, the RC may not be necessary (it would effectively just be the
last in a series of summaries).

Paul