Use stale bot for commenting on stale issues/PRs in Node.js core repo

[trivikr]

Is your feature request related to a problem? Please describe.
Comment by @bnoordhuis in #25209 (comment): we have a long (loooong) backlog of probably-stale issues that no one is looking at, with many where discussion has meandered so much that no one is really sure anymore what they're even about.

Describe the solution you'd like

• Use stale bot to comment on stale issues (discuss stale bot config in this thread)
• Comment by @joyeecheung in Using GitHub Lock App for closed issues/PRs on NodeJS core? #25209 (comment): Closing an issue after a period of inactivity, is more useful.
• Comment by @sam-github in Using GitHub Lock App for closed issues/PRs on NodeJS core? #25209 (comment): close but don't lock, but I think we'd want to do it based on activity, not time of opening. The literally oldest issues by open date actually have some activity, some of them are long-term tracking issues. Its more in the middle (not oldest, not most recent) where there seem to be some issues that could be dropped if there is no activity.
• Comment by @bnoordhuis in Using GitHub Lock App for closed issues/PRs on NodeJS core? #25209 (comment): I'd be in favor of auto-closing old issues.
• Comment by @manniL in Using GitHub Lock App for closed issues/PRs on NodeJS core? #25209 (comment): you can "announce" the close and give another grace period so the user can bump the issue again (if still relevant).

Describe alternatives you've considered
Manually finding out stale issues and commenting on them, like @targos did in #25209 (comment) 😜

[sagitsofan]

+1

[bnoordhuis]

I still think it's a good idea. It's not as if the number of open issues has gone down since last time, quite to the contrary.

[Trott]

@nodejs/tsc

[Fishrock123]

we have a long (loooong) backlog of probably-stale issues that no one is looking at

I do try to semi-routinely go through the issues backlog oldest-first.

I very much dislike auto-closing old issues, personally.
Maybe that's just because I do triaging weirdly, I don't know.

To me, the reality is that there are going to be a good chunk of unresolved things and, that's ok. At least it's a clear signal that any given issue there wasn't resolved and may be picked up.

Also, all things considered, I think we still do a pretty good job for the size of project we are.

[sam-github]

Just to be clear, most of the comments quoted in the description are in favour of closing stale issues, not old issues. Stale would be issues with no activity.

If a ping is published first to notify of upcoming auto-close, it should only take someone replying with "pls keep open" to make it unstale for some time (I'd assume it'd be a couple more months).

If no one can be bothered to post a "please don't close this" into an issue every few months... then I'd call it a good candidate for closing. Closing doesn't mean it can't be reopened on request, or commented on, or searched, or anything really. Primarily, it cuts down the number of things that have to be looked at when the open issues are periodically sieved through by someone generous with their time.

[mhdawson]

My cents would be:

• base it on x time since last activity in the issue
• Ensure the message added on close makes it clear we want those involved to re-open if it should still be open
• Provide a tag that can be used to tag issues that we think are ok to stay open with out activity for a long time. For example (although not a good example necessarily) it may be expected/ok for features requests we've reviewed and agree with to stay open even if there currently no ongoing activity. Backports might be another one, were some will sit waiting for the next SemVer minor release.

Seems like stale bot should be able to be configured along those line.

[trivikr]

The default configuration for staleBot is given in their README

Based on suggestions from @mhdawson:

base it on x time since last activity in the issue

• it's defined in daysUntilStale and daysUntilClose

Ensure the message added on close ...

• the comment can be added in markComment

Provide a tag that can be used to tag issues that we think are ok to stay open with out activity for a long time.

• the option is available under exemptLabels
• there's also onlyLabels, exemptProjects, exemptMilestones, exemptAssignees which we can use if required

Backports might be another one, were some will sit waiting for the next SemVer minor release.

• backports can be done even after issue/PR is closed right?

[trivikr]

Suggestion from @sam-github:

If a ping is published first to notify of upcoming auto-close, it should only take someone replying with "pls keep open" to make it unstale for some time (I'd assume it'd be a couple more months)

Their app states under point 2:

If the Issue or Pull Request is updated, or anyone comments, 
then the stale label is removed and nothing further is done 
until it becomes stale again.

So any activity on issue/PR will unmark the issue as stale

[trivikr]

Suggestion from @Fishrock123:

I very much dislike auto-closing old issues, personally.

• We can set a big value for daysUntilClose (like 3 or 6 months)

To me, the reality is that there are going to be a good chunk of unresolved things and, that's ok. At least it's a clear signal that any given issue there wasn't resolved and may be picked up.

• We can use use exemptLabels tags for such discussions

[mcollina]

@mhdawson stalebot does all of that. I would configure it so that an issue/pr become stale after 6 months, and get closed automatically after 1 year? This aligns it with our release cycle: essentially if it did not make it in 2 majors, then it likely won’t happen at all.

[trivikr]

The stale comment is just to notify subscribers that issue has been stale for a while (time of inactivity). Six months could be little long for that.
Can we reduce the time of inactivity?

[bnoordhuis]

Empirically, I'd say that > 50% of issues that have been dormant for a month, stay dormant.