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.

[trivikr]

As described in comment probot/stale#224 (comment), it looks like stale bot will comment on issues without staleLabel and remove staleLabel once there's any activity outside of stale bot.

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

How about these values?

• daysUntilStale: 60
• daysUntilClose: 365

The stale bot will comment on all issues without staleLabel after 60 days of inactivity, and close stale issues after 365 days of inactivity.

[trivikr]

I've created a feature request with stale bot to not include staleLabel while getting stale issues at probot/stale#225

If this feature request is implemented, stale bot will continue commenting after daysUntilStale of activity even if staleLabel is added.

[trivikr]

If there's no more update, I'll post a PR over next couple of days for stale bot config with following values:

• daysUntilStale: 60
• daysUntilClose: 365

Values for other configurations can be discussed in the PR comments

[targos]

For reference, here are the permissions requested by the Stale app:

[targos]

@trivikr do you know what will happen to existing issues after we enable it?
Are we all going to get hundreds of notifications at the same time?

[trivikr]

@targos I recently created config for lock bot (a different bot), which has a config called skipCreatedBefore which skips issues and pull requests created before a given timestamp (docs)

I don't see any such config for staleBot (docs)
I've created a request at probot/stale#227, and added block label for this issue

[trivikr]

Stale bot has a config called limitPerRun which defaults to 30
If we introduce stale bot now, I expect to get 30 notifications per hour till all stale issues are marked.

One way we could avoid this is to manually mark issues with staleLabel so that stale bot doesn't comment on them, but they'll be resolved if they are more than daysUntilClose (i.e. 365 days for us) old.

EDIT(trivikr): typo still > till

[devsnek]

I think it would be better to not limit the bot to a certain date range. Maybe we can set the limitPerRun lower, but we definitely should go through all our issues. At 30/hr it will probably take between 10/20 hours, which sounds reasonable to me, but if that seems overwhelming we can lower it to like 5/hr.

[trivikr]

The problem with too many stale bot notifications in the beginning is that some subscribers might miss genuine notifications if they clear all of them. Also, they might raise complaints after getting too many notifications.

The idea with skipCreatedBefore config was to add some date now, and reduce the date by some interval (say 3 months) regularly (say once every other week) so that:

• stale bot notifications are spread over time
• subscribers get used to stale bot notifications

For example, we start with value 2019-04-01 to skipCreatedBefore:

• two weeks from now, reduce it to 2019-01-01
• two weeks from then, reduce it to 2018-10-01
• two weeks from then, reduce it to 2018-07-01
• and so on...

Instead of fixed values (like three months), we can also update skipCreatedBefore based on number of issues/PRs which are stale (say 50 in one go) - with max 5 notifications each spread over 10 hours.

Each config update can be merged when subscribers won't mind notifications (say weekend?)

[trivikr]

GitHub announced Actions Beta today, which has an action for posting warnings and closing stale issues and PRs

• GitHub Actions https://github.com/features/actions
• Stale Action https://github.com/actions/stale

[bnoordhuis]

Are we moving forward with this? We're edging towards 800 open issues...

(Remember when we had only 500 open issues? Good times.)

[Trott]

Are we moving forward with this? We're edging towards 800 open issues...

(Remember when we had only 500 open issues? Good times.)

Aside: Hilariously, I've been trying to keep the number of open PRs down below 300 and was successful for a while, but now it all feels so hopeless. If you have an open PR that is realistically never going to be finished, please do me a favor and close it!

[trivikr]

Summary of configs discussed in this issue:

• Use stale bot for commenting on stale issues/PRs in Node.js core repo #28798 (comment)
• Use stale bot for commenting on stale issues/PRs in Node.js core repo #28798 (comment)

The issue created with stalebot at probot/stale#227 hasn't receive any responses.
There's an experimental PR in Node.js core to use GitHub actions CI for running tests at #29193

I've created new issue at #29232 specific to writing a stale action, as the discussions in this issue were mainly related to stale bot

[bnoordhuis]

Are we moving forward with this? We're edging towards 800 open issues...

We're over 900 open issues as of today. Can I suggest we move forward with either this issue or #29232?

[jasnell]

Does this need to remain open?

[trivikr]

Does this need to remain open?

Nope, we should go ahead with GitHub Actions discussed in #29232 instead.