Closed bmuenzenmeyer closed 11 months ago
the 90 days mark looks very aggressive to me.
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!
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 https://github.com/nodejs/admin/issues/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.
Perhaps as a compromise between the two expressed opinions (3 months, 18 months...) we could experiment with 9
. That about splits the difference.
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
Seeking consensus on:
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.
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
I am good with approach mentioned in https://github.com/nodejs/help/pull/4270#issuecomment-1773172948 . @mcollina - are you good too?
let's do it - this strikes the right balance
At the Node.js Collab Summit in September, I presented a small quantitative analysis of this repository's growth.
Within https://github.com/nodejs/admin/issues/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.