Using GitHub Issues for Python

In a 2018 Python Language Summit talk that was initially billed as "Mariatta's Topic of Mystery", Mariatta Wijaya described her reasoning for advocating moving Python away from its current bug tracker to GitHub Issues. She wanted to surprise her co-attendees with the talk topic at least partly because it is somewhat controversial. But it would complete Python's journey to GitHub that started a ways back.

Other Python projects are using GitHub Issues, she said, as are many popular open-source projects. Many people already have a GitHub account. When they run into a Python problem, they can immediately file a GitHub Issue, but might have to create a bugs.python.org (b.p.o) account before filing one there.

There is also the problem that b.p.o is maintained by just two people and its code is still in Mercurial, while most other Python projects have moved to Git (and to GitHub). There are lots of ideas about how to make b.p.o better, but the project is probably not really ready to accept a bunch of contributions if they were to materialize.

Wijaya said that she likes GitHub because of its APIs and the automation they allow. In addition, the email notifications contain useful metadata. You can also use Markdown and emoji in the text for GitHub Issues.

In order to migrate, the Contributor License Agreement (CLA) host needs to be migrated, either to something new or perhaps by using DocuSign, she said. After that, b.p.o could be frozen; it would be read-only, but not shut down. New issues would be created at GitHub.

Of course, there are still lots of bugs stored at b.p.o, with lots of comments and other useful information. The "old and languishing" bugs should be closed or ignored. For those that are still active, a button could be added to b.p.o to copy over the bug information and comments to GitHub.

Several core developers spoke up about the notifications from GitHub, which they saw as problematic. Barry Warsaw said he was concerned about getting "bombed" by mail from new issues; he likes the current model where he can decide what he wants to follow. Steve Dower said that GitHub notifications are "useless"; he loves the "nosy" list in b.p.o. Unless the notification problem can be solved properly, he is against the switch. He has yet to see a GitHub project that does notifications well; if that can be fixed, though, he would be in favor of moving bugs to GitHub Issues.

One of the problems is that b.p.o has its own mailing list where developers can scan for bugs of interest, which is not something that GitHub Issues supports. Wijaya thought it should be possible to create something similar for GitHub. She also pointed to the Octobox project as one possible way to deal with GitHub notifications.

Christian Heimes was concerned about losing the extra metadata that b.p.o provides for categories, priorities, and the like. GitHub Issues do not have anything like that. Wijaya thought that perhaps labels could be used to handle some parts of that; she also suggested that bringing the problem up with GitHub might lead to a solution. Others were not so optimistic; Nick Coghlan said that GitHub has not been responsive to the suggestions and requests from Kubernetes and other large projects, so it is not likely to make changes for Python.

Ned Deily thought there were a number of serious issues that need to be worked through before b.p.o could go away; it is not realistic to close thousands of open bugs, he said. But Guido van Rossum pointed out that Wijaya had said "old and languishing" bugs, not all of the open bugs. Copying the bugs to GitHub with a button is "great in theory", Deily said; the problem is that there are references and links to b.p.o all over the place. How would those get updated?

He believes moving to GitHub Issues is an even bigger job than moving to GitHub for repositories and pull requests. To start with, the project needs to understand how b.p.o is used in its processes today. But another attendee noted that there is a downside to not moving as well since pull requests and issues are well integrated on GitHub and that is not true with the current b.p.o setup.

It is clear that there are enough differing opinions that more study is needed, Van Rossum said. He suggested writing multiple PEPs that described the different paths forward. Those can be discussed on the mailing lists.

Van Lindberg cited some "passive-aggressive moves" by GitHub over the years that makes him concerned about centralizing all of Python development there. He wondered if there is a way out for Python and its data if things go poorly at some point. Van Rossum said that as things stand, all of the conversation in the pull requests would be lost when transitioning to another system.

But Carol Willing of the Jupyter project said that b.p.o is the "single biggest hurdle for new contributors". GitHub is not perfect, but you can take data out of it, she said; Jupyter does so for all of its projects. It is worth giving GitHub a shot, because right now Python is excluding contributors by continuing to use b.p.o. There is another downside to sticking with b.p.o, Brett Cannon said; there needs to be some plan for keeping it running, which is not something that anyone is really looking at. To stay with b.p.o, people need to step up to fix the problems and to maintain it. The status quo will not suffice given that b.p.o does not yet run on Python 3.