Make finding CPython issues without PR easier about core-workflow HOT 9 OPEN

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?

from core-workflow.

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.

from core-workflow.

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.

from core-workflow.

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:

• #465
• https://discuss.python.org/t/improve-communication-with-contributors-on-the-issue-tracker-and-prs-language-summit-follow-up/15812/

from core-workflow.

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?

from core-workflow.

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?

from core-workflow.

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?

from core-workflow.

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.

from core-workflow.

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.

from core-workflow.