Skip to content

Create stale.yml - #721

Merged
andymckay merged 2 commits into
mainfrom
add-in-stale
Nov 24, 2020
Merged

andymckay merged 2 commits into
mainfrom
add-in-stale

Conversation

@andymckay

Copy link
Copy Markdown
Contributor

We've got lots of stale issues and PRs on this repository. This will hopefully help clean them up.

@andymckay
andymckay merged commit 8c0ca1f into main Nov 24, 2020
@andymckay
andymckay deleted the add-in-stale branch November 24, 2020 22:52
@Marcono1234

Copy link
Copy Markdown
Contributor

Could you please reconsider this? In my opinion the default configuration of the stale action is in its current form contribution-hostile (see also actions/stale#56).

For example for #538 and #539 the bot wants to close the issue / pull request without any interaction from one of the contributors / maintainers. If you need more information, want any changes or don't like the changes please let me know. But having the bot just close them is really not nice.

Maybe a better solution would be to use the only-labels option of the stale action and then label any issue / pull request where you are awaiting a user response.

@andymckay

Copy link
Copy Markdown
Contributor Author

Thank you for pointing out that PR and issue, I've commented on or merged those.

A reduction in the number of issues and PRs would be an overall good for this repository, especially given the amount of spam and bots that write into this repository. Stale sends a ping to the watchers and let's them review the issue or PR when it occurs. At this point, I don't see a need to change that policy.

@Marcono1234

Copy link
Copy Markdown
Contributor

Thanks for the insight, I was not aware of the spam. Though I am worried that the situation becomes as bad as for https://github.com/actions/stale where the bot closed a lot of good issues. And indeed it appears the situation here is similar because most issues labelled no-issue-activity and some pull requests labelled no-pr-activity appear to have been inactive due to missing interaction by you, the maintainers 😕

Would an alternative be to have a label for good issues and pull requests, e.g. triaged (or alternatively use an issue template which adds a non-triaged label) and then one for issues and pull requests where you are expecting a response?
Then the bot could close all issues and pull requests without triaged label, or with awaiting-response label. This would still require that you triage them in time, but that would only have to be checking for non-spam (though maybe that would defeat the addition of the bot to tackle spam).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants