Maybe some one (who's good at writing) could make a closedforreasons.org and you could just put the link in and close the issue anytime someone posts such an issue.
The site could try to be as polite as possible, explaining that your time isn't free. You're not there to cater to them or give them free labor. You are interested in bug reports but only if they contain a minimal complete repo and explain what minimal means, what complete means, and what repo means. There could be common links like closedforreasons.org/mcve closedforreasons.org/rude closedforreasons.org/nofreelabor closedforreasons.org/notyouremployee closedforreasons.org/outofscope closedforreasons.org/askingfortutorial etc...
It will certainly piss some people off but maybe after a hopefully short while it would be seen as a gentle nudge by everyone that's been through it.
How can you have a closed because site without being able to write a custom reason, with custom parameters, and on top of that, it doesn't make my coffee. Ridiculous.
There's something similar to what you're proposing: https://idownvotedbecau.se/. It's tailored to Stack Overflow and the Stack Exchange network, but a lot of it overlaps with your proposal.
Having robust reply templates is pretty key. If the templates explain why a thing was closed, there isn't much for the user to refute. They can always fume, but fuming on a closed ticket is like screaming into the void. Leveraging bots helps as well. e.g. if an issue template isn't followed, removed, or omits key required info the issue is closed by a bot and a reply is dropped letting the user know that their attempt to circumvent the requirements means they get no support.
Bots are good in moderation, but in some cases bots can annoy everyone involved...
For example; the Angular repository has a "stale bot", which closes and locks the issue after a certain amount of time of inactivity.
This sounds great on the surface, however it's insane in practice. The users constantly need to recreate duplicate issues, as the original issue is locked. Most of the duplicates are not linked, so maintainers can't determine which issues are duplicates. And it also increases the friction of users notifying that the issue is still occurring.
Basically the result of "stale bots" is more duplicate issues and less engagement on old issues (as they're locked)
I manage a couple of high volume projects on a few open source initiatives. Stalebot is a sanity saver. Users are always welcome to trigger the bot to reopen. I won't presume your experience on open source projects of a big size, but when you're dealing with dozens of new issues daily, and have hundreds of issues that go back five years with no activity, the stalebot saves the day.
That speaks to another issue of open source - it's more common than not for a user to report an issue with no intention of following up, nor helping to triage (let alone contributing). Drive-by issues are noise and take precious time away from maintainers. There again, stalebot steps in to help. YMMV but my personal experience is that we don't get too many reopens, and we don't get too many duplicates from closed issues.
Only the original reporter gets to bump/reopen. Which they are sure to give up doing after a few iterations.
In addition, it's just plain rude. If you don't have time to fix it, that's valid, but what makes you presume you community has time to deal with constant bot reminders on order to keep the bug open?
You don't have to deal with it, that's fine, leave it there. Or get some more maintainers on board to help with triage.
I think you are also being a bit entitled here. Bug reports absolutely do take effort to file, especially good ones. Automatically closing bugs for inactivity shows that you don't value that effort. Personally, that would mean every future bug report to your project would receive minimal effort. If you don't like bug reports then you should not have a bug tracker at all. If you do have a bug tracker, try seeing it as a mutually beneficial exchange that is not free for either side.
Unless someone is contributing, it's not at all a mutually beneficial exchange. If someone reports a bug that affects only them (e.g. edge cases) then that ticket benefits only them. The -vast majority- of tickets files on large projects are for the benefit of single users. The tertiary benefit to users that might come along later with that same edge case or edge feature need are moot. It doesn't benefit the maintainers. If someone reports a bug and leaves out critical info because "they know better" than the maintainers, and that causes additional work for the maintainers that creates burden. Maintainers are already giving their time freely to produce something for users to use freely. The scales are always tipped in maintainers' favor.
Exactly. I'm not asking you anything here, I understand you don't have time to fix it, but leave it up so another contributor can find it. I'm literally asking you to not do something instead of doing something (closing).
I don't really like something like stalebot from both the maintainer and user side. As a maintainer, I don't want a legitimate issue to get closed just because it's not (yet?) a high priority for me, and I let it go for a while. And as a user, if I've provided sufficient information to reproduce the issue, and the issue is valid, it's really demotivating to have that issue closed by a bot.
I think stalebot works so long as maintainers commit to marking issues as "confirmed" after a while, or if enough people +1. However too often that is not the case.
Multiple times have I filed an issue, that collects many people's "me too" and workarounds for over a year. And every month, stalebot comes and mentions everybody, so that I have to go and type in that stalebot command.
Until one day I give up, because I don't want to get those notifications anymore, or because I move to a more active project. The issue gets closed even though multiple people are affected, and all they can do is open a new one, link to the workarounds somehow, and take over the duty of fighting the bot.
Why make everyone do this? You say you don't owe me anything, but that's different from taking active step to hurt your community.
Presumably if it's a "decent bug report", needing additional feedback etc is less likely, and I assume GP is more talking about bug reports that are not really usable without further information. (Although even if you are careful at providing information, you can easily hit cases where more information is needed)
This presumes that all opened issues are decent. It also presumes that the author of the issue responds to feedback. What I would quantify as drive-by issues include poorly written, lacking information, or providing information that results in a follow up reply from other users or maintainers with a fix or ask for more information that goes unanswered.
"library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
Closing bugs because they don't contain enough info and the reporter is not responsive to providing the required info is commpletely fine. Closing based on inactivity alone is just rude.
> "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
They could still be a hint that the documentation or reported error could be clearer.
We disagree. My experience with several extremely large projects has yielded the judgement that closing tickets which are years old without activity is prudent, as is setting a reasonable time frame in which an issue is too stale.
I quite like the idea of using bots - that way there's no human making a decision, and since we've already internalized bots as cold and unfeeling, no one's feelings are hurt.
IIRC, Gentoo does this, and my first patch was rejected multiple times. But because it was a bot that responded,I just felt like I had made a mistake, whereas with a human in the mix I probably would've asked a bunch of a questions and wasted her time and mine.
I'm going to disagree as someone who reports issues to open source. Often the templates request info I know as an experienced user of the software to be completely irrelevant to the issue, and if provided would only confuse the cause of the problem. Templates often assume a stupidity level of issue submitters. If there is a github template, I'll usually heavily modify the template and delete sections, which then gets flagged by a bot if such a bot exists. This only slows down the process of getting something fixed, not speed it up.
Frankly; it's not up to you to determine what info maintainers need - thinking otherwise is an entirely entitled point of view. That's why the project members and maintainers ask for what they need to triage not just your issue, but all issues from a wide variety of users on any variety of platforms.
If you can't take a few extra seconds to enter information in a template, why on earth should maintainers donate their time to you to triage what you're reporting?
While I agree with the point you're making, I'd like to point out the tone of your wording. It's not cruel or anything, but there are some pretty easy changes to it that could have made it an explanation instead of an argument.
As for the original point: I suspect every developer has encountered a bug in their code that couldn't possibly be caused by something, but ultimately was. Getting all the information requested up front in a regularly structured way, even when we think it's irrelevant, can make tracking these problems much easier.
A compromise could be to have a bot to check the issue template, but to make the bot aware of users' contribution histories. The bot would skip checking the format of someone's issue if, for example, they had already reported at least three bugs or gotten one patch merged.
This idea seems really interesting/promising. Here are three considerations I've thought of while thinking about how it might be implemented:
1. Many years ago (I only saw this here and there myself) a particular essay on Asking Smart Questions that would sometimes be linked whenever a suboptimal(ly worded) query was posted on a mailinglist or newsgroup or forum. http://www.catb.org/~esr/faqs/smart-questions.html
It's quite the wall of text, because it's thorough. This produces an unfortunate effect: everyone who reads the article, digests it, and applies what it says "disappears" into the bigger picture of people who ask good questions; while people who don't have the time to read an issue template properly have their eyes glaze over and they add the URL to their mental list of "evil entitled webpages that demand too much of my time" and go on filling the internet with noise.
TL;DR, a webpage this big: --> <-- works for just about everyone, but the "TLDR dropoff" is disillusioningly exponential beyond 0 bytes.
2. Taking as an example the common use case of people at the stage of learning about software development, there's a specific point in that learning process where everything seems possible... too possible. Of course it's possible to merge the Linux and Windows kernels. Of course it's possible to "just rewrite the codebase" to make the two mutually incompatibly designed components work together. One place that comes to mind that this sort of thing can concentrate is in game modding communities. It's not uncommon for there to be one or two "dev" type positions that are basically hacking it but have enough figured out to be competent, with a bunch of other users surrounding them that have no idea what they're doing and asking for the impossible. The net result is 500+ issues or forum posts, with only one or two ((ahem, achievable)) items slowly being acknowledged worked on, and the rest basically ignored for the sake of efficiency. The people that all have no idea what they're doing collectively think each others' ideas are great and if only the devs would actually listen to them the project might actually get somewhere.
TL;DR, accessibility and intuitivity are hard.
3. There are thousands of devs out there in situations where they simply don't have time to answer every possible question. They may honestly have a massive workload and are doing triage on top of that, they might be maintaining a minimum-viable free user support forum for a commercial product, they might be a time-poor OSS contributor, they may have laziness issues :P (independent of any other points here), they may have communication issues, ...
Again, there are thousands of devs out there who would be looking for a TLDR for their circumstance.
A large proportion of those that choose to use a template-as-a-service website to optimize their time can only pick from the best possible option from the available choices, even where the choices that are available aren't an exact fit, because this is a common pattern when optimizing.
Considering all of the above together, *you are going* to have circumstances where angry users will feel snubbed by suboptimally-chosen messages, and the challenge with a site like this would be to figure out how to reduce the chances that...
- almost-but-not-100% templates are chosen by time-poor devs for lack of better options, which will lead to poor reception of the site by end users
- the message is too long or complicated for the user to read and act on (can the user read English easily? Do they have intellectual issues (autism and ADD are particularly common, and drastically underaddressed) that make it hard for them to break work down into chunks and focus on it? Does the text of the template help the user to feel supported so they can calm down and focus on the work they must now do? Etc)
A couple of other points:
- Analytics would definitely be a good idea, as would actually looking through the supplied referers (that you can actually open).
- An "I didn't find anything appropriate for [URL]" option with a free-text "description" box would deliver a lot of helpful signal to further refine the options available
- Editing everything on GitHub or similar would make it straightforward for people to simply just contribute direct improvements (the "nothing appropriate" submission box would not be public)
The site could try to be as polite as possible, explaining that your time isn't free. You're not there to cater to them or give them free labor. You are interested in bug reports but only if they contain a minimal complete repo and explain what minimal means, what complete means, and what repo means. There could be common links like closedforreasons.org/mcve closedforreasons.org/rude closedforreasons.org/nofreelabor closedforreasons.org/notyouremployee closedforreasons.org/outofscope closedforreasons.org/askingfortutorial etc...
It will certainly piss some people off but maybe after a hopefully short while it would be seen as a gentle nudge by everyone that's been through it.