Decrease stalebot interval per collab summit discussion

[bmuenzenmeyer]

At the Node.js Collab Summit in September, I presented a small quantitative analysis of this repository's growth.

Within nodejs/admin#830 a group of us collaborators discussed actions to make the triage experience better here. Among the consensus at the meeting was to emphasize timely engagement here to avoid stale issues from going unanswered. That doesn't respect askers time or triagers time wading through years' old questions.

The goal with this action and more is to level-up the triage and help posture to such a degree that our aggregate triaging efforts can be best funneled toward the issues where posters remain committed to receiving help.

[bmuenzenmeyer]

self-review

[bmuenzenmeyer]

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

[bmuenzenmeyer]

open to other numbers...but in total this means that no activity in a THIRD of a year will close the issue. I think that sounds like a fair balance of empathy toward maintainer and asker time/schedules.

During the collab summit I also suggested multiple PRs that go from 3 years, to 2 years, to 1 year, to 6 months, or something like that... but it sounded good on paper and didn't land well with the audience...the only benefit is shortening what will be many notifications. Node.js collaborators are already used to a firehose and should have optimized the experience to their needs.

[gireeshpunathil]

the 90 days mark looks very aggressive to me.

• the voluntary nature of engagement means triagers (and collaborators too) who engage to help progress the issue) might catch attention of the issue at an unpredictably random time frame.
• potentially transient nature of issues will mean that the askers may not respond instantly to a suggestion, but may be after many weeks / months when they notice the issue next time or when they are in a position to apply the change control in their production.

In summary, while 3 years may be a little too long wait period, shortening it aggressively can inadvertently close issues that may be otherwise progressed and resolved. Having said that, an 18 months of staleness looks reasonable to me for abandonment.

As a side note, a more comprehensive way to address this is to institute a process in place that makes sure some regular trigger engagements in the repo, including running workshops to triage down the backlog. Happy to engage and help here!

[gireeshpunathil]

Suggested change

	There has been no activity on this issue for 90 days.
	There has been no activity on this issue 18 months.

[bmuenzenmeyer]

hey @gireeshpunathil - i gave you a very well deserved shout out in my slides -

and appreciate you weighing in on what a good balance should be.

As a side note, a more comprehensive way to address this is to institute a process in place that makes sure some regular trigger engagements in the repo, including running workshops to triage down the backlog. Happy to engage and help here!

Totally agree! If you check out nodejs/admin#830 you'll see that this is just one of 4 or 5 things we want to do to improve the triage experience - two of which are creating some triage guidance and regularly meeting as a triage team to help one another. I intend to find the time to organize that in the coming weeks and would be thrilled if you could make it.

[mcollina]

lgtm

I agree with this change. The tracker is out of control.

[bmuenzenmeyer]

Perhaps as a compromise between the two expressed opinions (3 months, 18 months...) we could experiment with 9. That about splits the difference.

[preveen-stack]

A graceful closure would be that done by the Author, who in many cases are not accessible for requests for more details.

Most issues are help requests which may not be in scope of nodejs development as such

If anybody who is well versed with nodejs internals can afford to spare the time to browse through the issues once a month or so, I think that will result in resolution of many issues that needs expert attention which @nodejs/issue-triage members are unable move closer to closure.

Making the closure deadline more aggressive will probably result in seeing number of issues reduced, but that is not serving the purpose of this repo.

I would suggest that automated tool should ping the author 3 times with 3 months duration between each ping, and if no response received we can go for automated closure

[bmuenzenmeyer]

Seeking consensus on:

• 11 month staleness
• 1 month closure after that

Here's a survey of what would be closed with this set of values:

387 of 653 issues with no activity for a year - or 60% closed
116 of them have no comments.

These aren't gone forever, they can be re-opened with a simple request.

[sheplu]

I do agree with the main point here, reducing the time we keep an issue open.

For the value itself, I think even 11 months is way too long. I would have been more than ok with a 90days delay but as this can be seen too aggressive maybe a middle ground at 6 months (180days) is something that would be possible ?

And a 30 days delay before we close it after that would make sense to me

[gireeshpunathil]

I am good with approach mentioned in #4270 (comment) . @mcollina - are you good too?

[bmuenzenmeyer]

let's do it - this strikes the right balance