I think the best case is:
- autoclosing issues which don’t provide required information, such as the node/npm version
- a duplicate checker which can figure out if there’s a relevant item in TROUBLESHOOTING.md
- passing this, a human closes the issue to properly triage and figure out if a bug can be fixed or an error message could be improved.
Now, 1 and 2 probably aren’t going to happen anytime soon - not sure what types of solutions are out there for that right now.
But I still don’t like autoclosure because when there’s autoclosing, people file issues over and over again for the same bug which burdens support and obscures opportunity for improvement, rather than being pointed to the existing open issue. Human closure seems to sort of work on Github - for example the see the npm Github issues/20999#issuecomment-397621091 which was recently manually closed.
There are around 400 reports for “error cb() never called!”. I’m sure that somewhere within those 400 issues, there is a bunch of knowledge that could be extracted for everyone else, and possibly an improved error message or bugfix. (Note to self: look through some of these issues and make a PR to the troubleshooting). Another example
is a bug like https://github.com/npm/npm/issues/18108 - I’m sure that there are multiple duplicate reports of this (I only found on 1). Once the person finds the workaround, they can address it, but if it was fixed entirely the support issues could be avoided. Fortunately it hasn’t been autoclosed.
Another thought: this is a tool for programmers. Making it as easy as possible to hack makes it easier for programmers to do their own support. If the bug report issue form suggests bisecting, maybe that will occur to people more readily. Possibly the dev environment could be more automated or straightforward - README.md CONTRIBUTING.md are a bit light on technical details. I’m running more and more of my apps from source so that I can quickly bisect regressions. Some open-source projects I use ship out-of-box IDE configurations so I can drop into a debugger immediately after cloning the repo. These days I can even do time-travel debugging with VSCode.