Make finding CPython issues without PR easier

[nineteendo]

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

[Mariatta]

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]

I think before we add this label, we should utilize the "triaged" label more.

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]

Or does it also mean a pull request will be accepted?

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]

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]

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:

• Remove the "invalid" label, add a "valid" label #465
• https://discuss.python.org/t/improve-communication-with-contributors-on-the-issue-tracker-and-prs-language-summit-follow-up/15812/

[nineteendo]

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)

If the issue is clearly invalid (unrelated to CPython, duplicate, spam, etc), you can use GitHub’s “Close as not planned” option.

[ezio-melotti]

Currently there's no way to find an issue without a pull request, you have to click on every issue.

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, bedevere keeps 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:

• issues that have linked PRs, using is:issue "gh-linked-prs", and
• issues that do not have linked PRs, using is:issue NOT "gh-linked-prs"

This is not as convenient as using linked:pr or label: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:

• seen/acknowledged;
• triaged;
• accepted as valid;

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-pr label could automatically be added to all new issues or when they are marked as valid, and then bedevere could automatically remove it when a PR is linked. However the other issues still need to be considered before creating another label.

[nineteendo]

This is not as convenient as using linked:pr or label:needs-pr, but it should solve the issue. @nineteendo is this solution acceptable for your use case?

I also thought of is:issue NOT "Linked PRs".

• This doesn't find issues with only closed but unmerged pull requests (false negative)
• This finds meta issues linking to other issues (false positive)

Besides these minor issues it's a fine work-around, but it's not obvious at all. A needs-pr label would be better for new contributors.

[terryjreedy]

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.