Comments (9)
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.
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
orlabel: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.
Related Issues (20)
- Add OS-ios label, and later OS-android HOT 1
- `blurb merge`: "No 'section' specified. You must provide one!" HOT 1
- Add label: OS-unsupported HOT 5
- Request for Python triage membership: Matt Page HOT 3
- Request triage team membership for Brett Simmers HOT 2
- Request for Python triage membership: AN Long HOT 3
- Request for Python triage membership: Malcolm Smith HOT 3
- Try out Datadog CI Visibility for CPython HOT 13
- Request for Python triage membership: Peter Lazorchak HOT 4
- Request for Proofreader membership
- Add the topic-repl label HOT 1
- Request for Python triage membership: Savannah Ostrowski HOT 2
- Add the "topic-JIT" label HOT 2
- Remove commit bit from inactive core devs HOT 11
- Require keeping an unreviewed PR open for a period of time HOT 5
- Generate notifications if PRs are merged without review HOT 1
- Request for Python triage membership: Bénédikt Tran HOT 2
- Add the `CI` or a wider `github-actions` label HOT 13
- Add the `topic-dataclasses` label HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from core-workflow.