In a local workshop introducing newcomers to CPython development, I was browsing through the issue tracker looking for things to work on. Many simpler issues are already being worked on—not surprising, but I was particularly frustrated that this is not easily identifiable when I browse the issues.
Take GH-138432 for example. It already has an associated pull request, and Bedevere correctly links it in the description. It also adds a reference from the pull request back to the issue. However, this is not enough to make the information visible in GitHub:
I compared the other issue that GitHub does indicate a linked PR. It seems like the difference is the other PR author included Fixes #138451 in their description (not by Bedevere).
Would it be possible to tweak Bedevere to use GitHub’s keywords, so GitHub understands the link between issues and pull requests to show it in its UI? This would be a very big improvement for contributors to identify issues that are not already worked on.
I was recently looking to start contributing to Python and ran into the exact same problem. Most recent issues either contained lots of discussion (and thus seemed far too complex for a new contributor), or already had open PRs. Being able to search for issues without PRs attached would be extremely helpful.
Unfortunately we cannot use the GitHub closing keywords, as that will automatically close an issue when a PR is merged, but often there are backports, or multiple PRs linked to one issue, so there is not a simple 1:1 relationship.
If there is a keyword that just references, rather than adding the closing relation, we could probably investigate that.
We could start to use the magic closing keyword more often. It’s a known problem we have lots of open issues (7,241 right now).
Yes, we can’t automate Bedevere to do so, because sometimes an issue is fixed across multiple PRs.
But we could manually use the keywords to close issues more often when the (final) main PR is merged.
Because we often forget to close issues after their PRs have been merged. Right now, we have 376 open issues with their linked PRs merged or closed. Some of these are intentionally left open because they need future work.
Yes, there are backports, but Miss Islington will comment when it creates or fails to create those, so there’s a ping. And we sometimes also forget backports, even with an open issue.
And it’s not like we have a rule to keep the issue open when there are pending backports – we often close the issue when the main PR is merged. Right now, we have 31 such backports awaiting merge where their issue is closed.
hi! I was encountering the same issue, so I wrote a little script using the GitHub Graphql API
to find issues without associated pull requests (cross references, not linked PRs)
