Repository navigation
Make finding CPython issues without PR easier #540
Description
Feature or enhancement
Proposal:
Currently there's no way to find an issue without a pull request, you have to click on every issue.
Would a "needs PR" label for issues without an open or merged pull request (closed doesn't count) help?
And to opt out for meta-issues, you could add "[META]" to the issue title.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Activity
[-]Make finding issues without PR easier[/-][+]Make finding CPython issues without PR easier[/+]Mariatta commentedon Jun 2, 2024
If the intention is to use this label to find issues that can be worked on by contributors, then I think it is not useful unless the issue has been triaged first (with the "triaged" label) which indicates that the issue has been accepted as "valid".
Looking at the current CPython repo, there are only a handful of issues that have been marked as "triaged", meaning the number of issues needing PRs and triaged will be even less.
I think before we add this label, we should utilize the "triaged" label more.
nineteendo commentedon Jun 2, 2024
Yeah, I would expect that when a triager has reviewed an issue it's either closed or it's marked as valid. Or does it also mean a pull request will be accepted?
erlend-aasland commentedon Jun 2, 2024
That depends on the PR; does it resolve the issue in a good way? does it introduce a breaking change? does it considerably add to the maintenance cost?
nineteendo commentedon Jun 2, 2024
Assuming the first 2 (otherwise it's just a bad pull request). Does "triaged" also mean that maintenance is not an issue, or does it simply mean that it's valid?
hugovk commentedon Jun 2, 2024
The "triaged" label simply means a triager has processed an issue, things like this: https://devguide.python.org/triage/triaging/
The issue wasn't an obvious "close right now", but it's still possible another triager or core dev will close it later.
Triaging isn't a black-and-white thing, it's more of a process. A triager might have a first pass and add some labels. But someone else might do some more later. I think is partly why it's not used very much. I don't use it.
Previous discussion:
nineteendo commentedon Jun 2, 2024
With valid, we simply mean it's not clearly invalid. So, I don't think it being triaged should be a requirement. (A sane person should be able to identify this)
ezio-melotti commentedon Jun 3, 2024
GitHub actually has a built-in feature for linking issues and PRs, which is also visible directly from the issue list:
It is also possible to search for issues that don't have a linked PR, using
-linked:pr.However this feature conflicts with our workflow: linking a PR means that the issue is automatically closed when the PR is merged and we often want to backport the PR before closing the issue. The feature is therefore rarely used.
Because of this,
bedeverekeeps track of linked PRs by editing the first message of the issue whenever a PR that referenced it in the title is created. The list of linked PR is within a couple of<!-- gh-linked-prs -->tags, and this can be exploited to search for:is:issue "gh-linked-prs", andis:issue NOT "gh-linked-prs"This is not as convenient as using
linked:prorlabel:needs-pr, but it should solve the issue. @nineteendo is this solution acceptable for your use case?Label-related aside
Previously we discussed somewhat similar labels to mark that the issue had (not) been:
Your proposal would mark the next step in the workflow: once the issue has been seen, triaged, and accepted as valid, it will need a PR that fixes it. Then the PR will need to be reviewed, accepted, merged, and possibly backported, before the issue can be finally closed.
These steps have some overlapping, and we need to find a balance between the granularity of the labels, their usefulness, the convenience they bring for searching/filtering, the burden of adding/removing them, the visual clutter they add to the issue and issue lists, etc.
The burden of adding/removing them could be limited with some automation when possible. For example, a
needs-prlabel could automatically be added to all new issues or when they are marked as valid, and thenbedeverecould automatically remove it when a PR is linked. However the other issues still need to be considered before creating another label.nineteendo commentedon Jun 3, 2024
I also thought of
is:issue NOT "Linked PRs".Besides these minor issues it's a fine work-around, but it's not obvious at all. A
needs-prlabel would be better for new contributors.terryjreedy commentedon Jun 4, 2024
The problem with a label is that nearly all opened issues initially need a PR. Removing it would have to be automatic. Closing issues should also remove it. Meta issues need linked issues.
The work around should be in the devguide.
AA-Turner commentedon Aug 12, 2025
Closing, stale.