Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
"Inactive" workflow: add close label for inactive issues#25999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
.github/workflows/stale.yml Outdated
| @@ -18,6 +18,7 @@ jobs: | |||
| days-before-pr-close: -1 | |||
| stale-issue-message: 'This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!' | |||
| stale-issue-label: 'inactive' | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Did we want to change this to "status: inactive"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
If we do I think we need to delete the existing "status: inactive" label and rename "inactive" --> "status: inactive". I'm happy with that if others are?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Given that there are only two issues with "status: inactive" it's probably easy to delete the label, and then reapply it to those two. I can't see anyone objecting to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I've un-tagged the two issues:
- 19664 (non-reproducible bug)
- 19380 (completed)
But there are several PRs using "status: inactive". I've gone through them and removed the label where it was not appropriate anymore (reason in parenthesis):
- 17171 (upstream issue)
- 15383 (orphaned)
- 15065 (superseeded)
- 12365 (not a valid solution)
- 11577 (codebase has deviated too far)
- 11281 (relabeled to "orphaned PR")
- 11231 (other decisions pending)
- 10273 (we likely don't want this)
- 10049 (superseeded)
- 9941 (superseeded)
- 8915 (orphaned)
- 8700 (we likely don't want this)
- 5598 (superseeded)
- 7894 (activity after the labelling)
- 16005 (activity after the labelling)
There are 2 open PRs and 28 closed PRs remaining, which should be in an state that matches our current interpretation of "inactive".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
tl;dr: Don’t worry too much about that.
These were basically all closed due to inactivity. While I have reservations on closing issues due to inactivity. I‘m much more relaxed on PRs. Issues describe a fundamental property (bug/ feature request) that relevant in a general sense. It’s not generally clear who can/should act on these. OTOH, PRs are specific implementations suggested by a contributor. If that contributor is not following up (which was the case for all closed-inactive PRs) closing after some time is viable. In general, the value of PRs in such a state is limited: It‘s not been ready for merging, and if long enough ago reviving may be difficult due to code changes in the mean time. So being able to find them by label is not too important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I wish we still had that activity feed in gitter, as it showed every change of a label. So I might have realised you were doing something more involved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks! This addresses part of my concerns with the auto-closing of issues.
Not sure if/how this should be milestoned, so putting it at 3.8 (so that it is milestoned, but not backported). |
Thanks All. I have updated the "inactive" label to status: inactive |
PR summary
To partially address concerns raised within#25938, this PR will have the stale action add a label to any issue it closes (currently "status: closed as inactive" but better suggestions welcome). This will make it more explicit why the issues were closed and also make it easier to find and retrospectively review issues that were closed by the bot.
PR checklist