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

Paul Moore p.f.moore at gmail.com
Sat May 19 06:36:25 EDT 2018

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

More information about the python-committers mailing list