6 ms·

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 is

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.

exikyut 6y ago
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 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)
- geoduck14 6y ago
  .
blargpls 6y ago
There's something similar to what you're proposing: https://idownvotedbecau.se/ https://idownvotedbecau.se/. It's tailored to Stack Overflow and the Stack Exchange network, but a lot of it overlaps with your proposal.
- aloisdg 6y ago
  Came here to post that. It save a lot of time. It is more friendly and useful https://lmgtfy.app/ https://lmgtfy.app/. Far more relevant and less passive-aggressive.
andrew_ 6y ago
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.
- necrotic_comp 6y ago
  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.
- gitgud 6y ago
  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) Moral of the story, use bots in moderation
  - andrew_ 6y ago
    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.
andrewaylett 6y ago
Your wish is my command: https://closedbecause.xyz/ https://closedbecause.xyz/ Source here: https://github.com/andrewaylett/closedbecause.xyz https://github.com/andrewaylett/closedbecause.xyz, suggestions for reasons welcome, PRs even more welcome.
- _underfl0w_ 6y ago
  It would be neatly recursive if someone opened an incomplete/nonsense PR on the repo for this site, prompting a link to the site itself.
- dastx 6y ago
  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. (Joke obvs. Sorry, couldn't resist.)
- worik 6y ago
  Well done!!
- cyberfart 6y ago
  A relevant post, "Open Source is Not About You" by Rich Hickey. https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
- dumpsterdiver 6y ago
  Appropriate use of an xyz domain IMO, it's catchy. Bravo.
emilecantin 6y ago
Great idea! I was looking for a side-project I could do in a week or so, so I just bought the domain and I'll build it.
dmckeon 6y ago
Came across this explainer site the other day: Short, Self Contained, Correct (Compilable), Example http://sscce.org/ http://sscce.org/

exikyut 6y ago

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 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)

geoduck14 6y ago
.

blargpls 6y ago

There's something similar to what you're proposing: https://idownvotedbecau.se/ https://idownvotedbecau.se/. It's tailored to Stack Overflow and the Stack Exchange network, but a lot of it overlaps with your proposal.

aloisdg 6y ago
Came here to post that. It save a lot of time. It is more friendly and useful https://lmgtfy.app/ https://lmgtfy.app/. Far more relevant and less passive-aggressive.

andrew_ 6y ago

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.

necrotic_comp 6y ago
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.
gitgud 6y ago
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) Moral of the story, use bots in moderation
- andrew_ 6y ago
  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.

andrewaylett 6y ago

Your wish is my command: https://closedbecause.xyz/ https://closedbecause.xyz/ Source here: https://github.com/andrewaylett/closedbecause.xyz https://github.com/andrewaylett/closedbecause.xyz, suggestions for reasons welcome, PRs even more welcome.

_underfl0w_ 6y ago
It would be neatly recursive if someone opened an incomplete/nonsense PR on the repo for this site, prompting a link to the site itself.
dastx 6y ago
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. (Joke obvs. Sorry, couldn't resist.)
worik 6y ago
Well done!!
cyberfart 6y ago
A relevant post, "Open Source is Not About You" by Rich Hickey. https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
dumpsterdiver 6y ago
Appropriate use of an xyz domain IMO, it's catchy. Bravo.

emilecantin 6y ago

Great idea! I was looking for a side-project I could do in a week or so, so I just bought the domain and I'll build it.

dmckeon 6y ago

Came across this explainer site the other day: Short, Self Contained, Correct (Compilable), Example http://sscce.org/ http://sscce.org/