The CPython contribution guide at Lifecycle of a Pull Request currently says you should create both a GitHub Issue and a PR for any change.
As a very casual contributor to CPython, I find this workflow/requirement uncommon as far as GitHub contribution workflows go and somewhat annoying due to the overhead it inflicts. It frustrates me enough that it discourages me from contributing to CPython.
Many of my open source contributions start and end with a code change. I write detailed, self-explanatory commit messages / PRs. Most bugs/issues are going to require PRs to fix eventually. So why not just skip the project/issue tracking overhead and jump straight to the self-describing commit/diff/PR? At least that’s what goes through my mind when contributing to most open source projects. And many other projects seem to have no trouble practicing this workflow - especially those on GitHub.
Perusing through recent CPython PRs, it seems many PRs are associated with an issue filed mere moments before the PR. See e.g. Tkinter: test_getint incompatible with Tcl 9.0 · Issue #104411 · python/cpython · GitHub and gh-104411: Update test_getint for Tcl 9.0 by chrstphrchvz · Pull Request #104412 · python/cpython · GitHub (randomly selected recent example). This just-in-time behavior seemingly implies a lot of PR authors are creating issues just to fulfill the process requirement that an issue exist.
You may have noticed that on GitHub, issue and PR numbers share the same monotonically increasing integer namespace. URLs for the wrong item type redirect to the other. Using our example above,
https://github.com/python/cpython/pull/104412 are canonical but
https://github.com/python/cpython/issues/104412 redirect to them just fine.
Back when bugs.python.org was a thing and code and issues were discussed in different places, there was stronger justification for mandatory annotations to keep everything in sync. But with issues and code changes under one roof in GitHub, this justification seems weaker now.
What is the current justification for having an issue for every PR?
Is there room to allow PRs that don’t have a corresponding GitHub issue?
If separate issues (even just-in-time issues) are providing a benefit and there must be an issue for every PR, perhaps the workflow could be improved so contributors aren’t burdened with filing an issue? e.g. perhaps some bot can recognize when a PR is merged without an issue and create the issue post facto. This way we have the separate issue without imposing overhead on contributors. Seems like a win-win?
I want to underscore that this feedback is shared out of a mutual desire to improve the state of the [C]Python ecosystem. As I’ve learned from working professionally in developer productivity for 10+ years, every extra development hurdle / barrier matters and discourages contributions. In corporate settings it inhibits cross-team contributions. In open source it filters out potential contributors and undermines community diversity because of various survivorship biases (e.g. parents with limited time may contribute to a project that doesn’t impose workflow overheads).
Is it time to reconsider the necessity of GitHub issues for [C]Python contributions?