Repository navigation
Conversation
| # closeComment: > | ||
| # Your comment here. | ||
| This stale issue is now closed due to inactivity. Please re-open or re-file if | ||
| if the issue is still relevant. Thank you! |
There was a problem hiding this comment.
I think this message is missing the comment #s so it'll probably end up being tacked onto the end of the markComment. We also updated the messaging in the vmclarity/kubeclarity repo so there was a bit more info about a) what the criteria for stale was
b) when its likely to be closed.
https://github.com/openclarity/kubeclarity/blob/main/.github/stale.yml#L30-L44
There was a problem hiding this comment.
Great catch with the comment # - that's what I get for quickly copying config from one repo into another :D
I used some of the KubeClarity stalebot messaging as inspiration for creating this PR (see also openclarity/kubeclarity#432). As far as hardcoding the 'number of days' until stale/closed, my concern with baking that into the message text in our .github repository default means it's likely someone will forget to update the values in multiple places (the idea with this PR is that we introduce a more aggressive default setting, but encourage maintainers to override with their own values as needed). Thoughts?
ghost
left a comment
ghost
left a comment
There was a problem hiding this comment.
I think we need to fix the closeComment section before we can merge this
|
Closing in favor of #14 |
As discussed, let's dial the org-wide StaleBot defaults down, and allow individual projects to override these settings at the repository level, should they need them to be less (or more) aggressive.