Mariatta .

PEP 581 and PEP 588: Migrating CPython's Issue Tracker

8/17/2019 | 10:15 AM-10:40 AM | Robertson


In 2017, CPython codebase was moved to GitHub from Mercurial, an effort that took more than three years of planning and lots of volunteer coordination. The move proved to be successful and well-appreciated. New contributors face less barriers when contributing to Python. Core developers are benefiting from personal assistants in the form of GitHub bots and automations. Can the workflow be even better? In this talk, we'll look into other problems in CPython's workflow: the issue tracker itself.

The acceptance of PEP 581, by Python steering council means that another big workflow change is impending. Let's hear about some of the proposed plans on improving CPython's workflow, and learn how you can help and take part in this process.



  1. Brief introduction to core Python workflow. It's complicated. (5 minutes)
  2. The issue tracker is called bpo (an instance of Roundup)
  3. Codebase and pull requests are done in GitHub:
  4. Contributing guide:
  5. CPython discussions aren't normally not on GitHub, but on mailing list (python-dev, core-mentorship) and discourse

  6. GitHub is a new thing for Python (3 minutes)

  7. PEP 512: Migrating source code from Mercurial to GitHub
  8. Some pain points: core devs and Python release managers have to learn and adjust to a workflow. (it was not an overnight success)
  9. On the good side: it opens up oppurtunities to contribute to core workflow improvements, and still making big impact: devguide improvements, bots(bedevere, and miss-islington), toolings like blurb and cherry-picker. Contributing to Python is easier on GitHub.

  10. Should I stay or should I go? (3 minutes)

  11. bpo works, but it is not up to date with recent advancements: no emoji support, unintuitive UI, not mobile-friendly.
  12. bpo's development is hindered and stagnated.
  13. we're losing potential contributors just because the tracker is bpo.
  14. lack of existing API from bpo making it hard to automate things.

  15. Let's Use GitHub Issues already! (7 minutes)

  16. It is not as simple as "just copy over a bunch of tickets to GitHub"
  17. Some of us fear the uncertainties: GitHub is not open source, corporation owned, it could one day disappear without notice?
  18. What we're already doing: daily backup of GitHub data. starting to use CLA Assistant. We've asked GitHub to grant us early access to the "issue triage".

  19. What we still need help with (7 minutes) -- A professional project manager, similar to how PyPI/Warehouse project was handled. Steering council has opened this discussion with The PSF. -- We will have a "trial" issue tracker repo. We need to port 100s of tickets from bpo to GitHub. We need experiments and feedback. -- You can help update Devguide on how to use GitHub issue tracker and how to triage/add labels etc. -- We need more people to help triage issues. We've been able to grant bug triage permission more easily than granting commit privilege. Hear Emily's talk on being a core developer. -- If you have other ideas of improvements: write to python-dev, Use PEP 581 or PEP 588 in subject (to get my attention) -- Donate to The PSF. You can now donate directly for CPython's development: