The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
"Auto Closing" issues on this new platform
I’m liking this new discourse forum so far but I have a question about one of the settings/plugin that is currently enabled. There seems to be an “auto close” feature that has closed some topics before there has been any conversation and is going to close my latest question in 3 days.
Firstly I’m assuming that my question has such a short timeline because of the trust system that seems to be implied by the badge feature (not 100% sure how it all works) but that kinda brings me to my point. Since this is such a brand new community should we probably disable that feature initially because:
- there are so few people on here already that it’s less likely that there will be a response
- if there is a trust system for noobs then everyone is new so it will be a bit overzealous initially
Just a thought
The auto close times are based on how long we realistically think it’ll take before something is essentially buried. If we can’t respond within that time frame, I can almost guarantee we never will, based on experience.
In some cases, we’ll remove the deadline, or extend it to a longer time frame, but I believe the current numbers are pretty good to start with.
Keep in mind that we haven’t opened the flood gates to make this the default issue tracker yet, but once we do, it’ll be a ton of traffic. I’ve been setting things up with that near future in mind, as opposed to treating this like a small but growing community. We’re going to get -slammed- soon.
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.
Another example of autoclosing being unfortunate: I was looking at bugs and noticed that global install of shrinkwrapped package fails with ENOENT: no such file or directory, rename was reproducible - what if I do some investigation or make a PR? I can’t leave a comment there cross-referencing my work for anyone else to find and possibly build upon.
It could be that this is the right workflow for the NPM community, but I will point out that “open issues” is not really a problem on a forum like Discourse. Closing is much more important on GitHub Issues because it counts as “stuff that has not been fixed yet” and GitHub shows the number of open issues very prominently, constantly reminding you of this TODO-list.
Discussions are different. Someone’s question might go unanswered for weeks until someone else bumps it with the same question, making it obvious that this is a recurring problem that merits revisiting.
This is true! They’re definitely different tools and I admit part of this is me reacting to a reality based on GitHub.
It might be worth considering removing the auto-closer for #bugs. I’m inclined to keep it for #support because the nature of support problems is that if they don’t get an answer within a few days, all future comments are more likely to be noise than have anything resembling signal.
That said, I also think it’s healthy to make new topics for bugs instead of keeping a single one open long-term. My experience with that is that people will Google a single keyword and then add useless “yeah I got this too” comments.
@iarna and I talked about this and we decided that we still want to have this timer, but we’ll make it longer: 2-3 months is about the line where a certain bug repro is less likely to be trustworthy, so we’re just gonna bump it up. The idea is that if after those 2 months, someone else rolls in and manages to reproduce it, they should post the new repro and that’ll refresh the timer.
This feels like a nice middle ground, thanks for taking the time to consider this in depth
@zkat I assume that if someone is able to reproduce an issue after the timer has lapsed and they link back to the original issue it will show up in some way (kinda like a github style back link)? I’m just trying to consider people “getting lost” while googling and then ending up on a closed issue that they can’t post a comment to.
yup. Discord has its own cross-linking mechanism. I’m not too worried about it being hard to find things like that.