11 ms·

I have a slightly different experience. I find aggressive users very easy to ignore. What does drive me mad is that some non-hostile users put zero value on my

by oefrha 6y ago

I have a slightly different experience. I find aggressive users very easy to ignore. What does drive me mad is that some non-hostile users put zero value on my time. I’ve painstakingly implemented debug logs and carefully prepared issue templates yet I still get these “does not work (EOM)” (effectively) issues. In the back-and-forth that ensues, sometimes it takes three or four attempts of asking the same question to get what I need, possibly separated by a day each time. Sometimes they’ll eventually realize what they missed was documented in the first place and would have been obvious if they followed the issue template to begin with. Then there are users expecting me to help with an incomplete, out of context code snippet, or quite the opposite, with their 5k LoC repository, hoping I’d fish out the 50 or 5 lines that are actually relevant on my own. These users are not outright assholes, so it’s somewhat harder to justify passive-aggressiveness against them. And they may have actual issues locked behind three or four back-and-forths. (For the record, I got maybe a total of $10 in donations from thousands of hours of FOSS work. Actually a high profile project I worked for did receive sponsorship, but nothing went into my pocket for obvious reasons.)

opportune 6y ago
I understand when writing paid software with support expectations/contracts, sometimes you have to engage with the teeth-pulling exercise that is “does not work”. But why do you in FOSS? Can’t you just close the ticket and say “not descriptive enough” and move on?
- StavrosK 6y ago
  You can and I regularly close tickets for not following the template that says at the very top "tickets not following this template will be closed with no reply". It's even better if you can get a bot to automatically reply and close it.
  - Tehnix 6y ago
    I was thinking about how one could automate this when reading. Not a foolproof way, but add a string in your Issue Templates that is required to be there, e.g. . If this is not present in the issue, the GitHub action just closes the issue with a message to please fill in the template if they wish to create an issue. Doesn't catch nearly everything, but should get some and it's easy to set up. Could be interesting to go further with the idea and maybe check if each section contains text or something like this, hmm...
    - StavrosK 6y ago
      I've seen this in repos, I'm pretty sure there are bots who implement it. I'd guess it catches more than 90% of cases, especially if you put the string at the bottom of the template.
    - a1369209993 6y ago
      Another, somewhat more underhanded trick: add a string that is required to not be there, e.g. "Please remove this line entirely.", halfway through the template, and mention it nowhere else.
- oefrha 6y ago
  You can. You can do anything, really, including not reading issue reports at all. But you set out to be helpful anyway, so it’s about finding a cutoff where you don’t want to help anymore. As I said, it’s simply harder than ignoring assholes. (Plus you may get a bad rep.)
- hombre_fatal 6y ago
  To do that, you need a healthy brutal self-respecting trait that I think most of us admire. The rest of us feel bad doing that, especially towards someone trying to use something we built ourselves that holds some measure of our own pride or even self-worth, it feels closer to obligation. So we waste our time trying to help the characters that deserve our help the least, and we learn to develop a resentful version of that trait over a period of decades.
  - proactivesvcs 6y ago
    The Syncthing project will often apply this trait and you're right - it's admirable as well as pragmatic.
  - pbhjpbhj 6y ago
    Sounds like a good way for someone without coding skills to help a project, bug/message triage. But then, a good bug-reporting system should be able to do such filtering? I'm wondering if detecting abusive communications is/could be part of it, bit of ML seems like it would fit, even just some Bayesian filtering might do. One could also train an NN to recognise images of the app (or simpler: OCR|grep) and require a screenshot with any submission. But I guess automated triage mightn't be the best route. It seems very much a delicately balanced people problem.
  - madeofpalk 6y ago
    It's a skill probably worth practicing.
  - matz1 6y ago
    Like anything else, the more you do it the easier it gets. Its not going to be instant but you'll get used to it.
  - kelnos 6y ago
    I don't think you even need to be that brutal. Just have a file on your hard drive with a canned response that instructs the reporter that they need to provide more information, and how to provide it. Every time you run into a weak bug report, copy-paste that response into the issue comments. If the extra info gets provided, great, now it's a useful bug report. If not, you can close the issue, and not feel anywhere near as bad about doing so.
- bxnkL 6y ago
  Depends on the project. If it is governed by bureaucrats and you do that too often, you'll be accused of "not being inclusive". The modern version of "Boxer the work horse should work harder".
- teekert 6y ago
  Honestly sometimes the amount of things that you need to fill out just makes me use other software. I.e. kmail would never remember that I want my email threads expanded (this example is not real, the kmail devs were very helpful with minimal info in this case). Does this really require I hunt down all this info from all around the place? Sometimes I don't even know where to get the info. What helps immensely (and I saw this in the Geyser MC project), the software can produce a snippet with all info the devs want with one command, and it even exports to pastebin taking out sensitive info. If you paste such a link in their Discord it even makes an overview with syntax highlighting in the chat. That really helps a lot on my (bug reporter) side. And thus on the dev side.
  - oefrha 6y ago
    If you can’t be bothered to copy a few version numbers when trying to get free support, kindly “use other software”. People providing free support usually don’t give a damn about your “taking your business elsewhere”. Moreover, - People omit things they think are irrelevant, when they are. - I print all the relevant details when --debug is on, so people just need to copy that. Some people refuse to run that and insist on submitting “does not work”.
    - teekert 6y ago
      I understand the -1, but you have to understand that to a user the choice is sometimes between: 1. Create crappy bug report and move on quickly to get things done or: 2. Do not create a bug report and move on immediately, to get things done I try to file whenever I can but when it's getting late and I want to go to bed I choose option 1 sometimes. Maybe I should choose option 2? For example, take the Nextcloud bug filing template on GitHub [0]. It's quite a long read but sure, worth the effort for free software I agree (Nextcloud is my favorite project, my life is in there, on my server)! However, I may not know exactly where these things are: ``` #### Web server error log <details> <summary>Web server error log</summary> ``` Insert your webserver log here ``` </details> #### Nextcloud log (data/nextcloud.log) <details> <summary>Nextcloud log</summary> ``` Insert your Nextcloud log here ``` </details> #### Browser log <details> <summary>Browser log</summary> ``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ``` They also want config.php, contents of `sudo -u www-data php occ app:list`, ask you to do this: Login as admin user into your Nextcloud and access http://example.com/index.php/settings/integrity/failed Also all versions: ### Server configuration \*Operating system:\* \*Web server:\* \*Database:\* \*PHP version:\* \*Nextcloud version:\* (see Nextcloud admin page) \*Updated from an older Nextcloud/ownCloud or fresh install:\* Moreover, I'm quite afraid to put my domain names or even more sensitive info onto a public website if I just copy and paste. All I'm saying is that a big button that generates everything a dev needs with sensitive stuff redacted (which should be doable here and yes maybe I should make a PR for that) will make the experience a lot nicer for the reporter and the dev. As said, the Geyser MC project [1] can do exactly this and to me it is a game changer, the whole process was fast and pleasant and it was easy to test the automated builds they made in the branch based on my issue and report back in context on GitHub. Pasting the JSON their report feature generates into their Discord channel together with your question and their ability to just !docs/something point you to relevant docs with a small command feels like magic. I found the whole process inspirational. I love all FOSS devs. You are my heroes. [0]: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C+0.+Needs+triage&template=Bug_report.md https://github.com/nextcloud/server/issues/new?assignees=&la... [1] https://github.com/GeyserMC/Geyser https://github.com/GeyserMC/Geyser
- LoSboccacc 6y ago
  this is extremely frustrating for the users. there's a game I used to play fairly often before updates simply broke it. like mission items were replaced with random fires floating in water. many users with the same issue reported it, and some like me even provided a save (which was never even downloaded) all such tickets were closed with "cannot reproduce" I'm not (their) tester, I don't have time to fully reproduce issues step by step, and I don't have access to a debug build anyway to figure out the bug trigger condition "does not work" is the best I can say here.
  - joncampbelldev 6y ago
    Was the game free? And did the people working on the game contribute a lot of their time to it for free? If not then I can see the reason for your frustration, however it is not the same as free software being worked on (at least partly) by volunteers receiving the same lack of effort (or in signal's case nastiness) in bug submissions.
    - LoSboccacc 6y ago
      paid
Abhinav2000 6y ago
> (For the record, I got maybe a total of $10 in donations from thousands of hours of FOSS work. Actually a high profile project I worked for did receive sponsorship, but nothing went into my pocket for obvious reasons.) Can you expand on the last bit? Is it common for sponsorship not to go to the actual developers working on the project and getting eaten by middle layers of bureaucracy?
- oefrha 6y ago
  I never saw a dime and never looked into spending details, but to the best of my knowledge, sponsorship money largely went to hardware for infrastructure; then some went to sponsoring physical meetups, e.g. reimbursing travel expenses of team members who attended FOSDEM. It’s not a lot of money so if everyone gets paid I suppose it would only be a token amount.
  - Abhinav2000 6y ago
    Thanks!
saargrin 6y ago
you are a true hero :)
imtringued 6y ago
You need a consistent process that you can point your users to. If they don't follow the process then politely explain that this will save time for both parties.
- oefrha 6y ago
  I do. It’s in the issue template, it’s in the wiki (pointed to by issue template), and commonly seen error messages may even point to the relevant wiki page. People who don’t care don’t care.
asiachick 6y ago
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)
YorickPeterse 6y ago
Over the years I've learned there's a class of users that simply don't read. Example: for GitLab we stopped using the repository that used to host the code for GitLab CE. All issues were closed, and when you create a new issue there's a template active that basically says "Don't create issues here". In spite of that, people still create issues here, and in some cases don't even bother changing that template.
- enriquto 6y ago
  This sounds like an UI problem. Why can't the system just disable the issue creation button?
  - kubanczyk 6y ago
    Yeah. It's literally one checkbox lacking on GitHub. So (1) Scrape the old, closed issues to a static website, link it from README.md. (2) Disable Issues in GitHub's repo settings. Part 1 is somewhat complicated, because issue-to-issue linking.
- smeej 6y ago
  I've spent more than a decade in customer/user-facing roles, and that class of users is actually "almost all of them." But it's worse than that. Most people do not have the reading fluency to read more than a few words in a sentence without getting frustrated and confused. If your work peers and social groups consist of the 3-5% of people who aren't in that category, it can be easy to forget that. Any time you can make something's function clear with one or two words and design, opt for that over explanation.
  - BurningFrog 6y ago
    And this is why UI/UX experts are so valuable in software projects!
  - crznp 6y ago
    If "almost everyone" fails some expectation, is the problem with the people or the expectation? The average user might not be super invested in the application, they just know that something doesn't work, which is frustrating. If their only outlet for that is a bug report, the developers get overwhelmed with bad bug reports and users get the expectation that the developer is going to fix all their problems for them. If the outlet is a feedback form instead, maybe the user can feel listened to in a small way and move on. The developer doesn't have to sift through a bunch of issues, they can just follow up if there seem to be any hot-spots that are causing a lot of frustration.
sampo 6y ago
Could issue boards have volunteer community moderators, like Reddit and StackOverflow have?
raxxorrax 6y ago
I think a problem is the social integration of sites like Github (I assume you have your project there). Traditionally low-effort questions were filtered out because many users didn't want to get into the trouble of contacting developers directly. Although it wasn't unheard of, but there was probably significantly less noise.
nousermane 6y ago
What you are describing is a perfectly typical (and expected) behavior for a user of a commercially-licensed library/server software. Many developers/admins use both FOSS and COTS, and feel the same low-effort interaction with upstream is okay in both cases. It's possible to educate a small number of your users (and to a some extent, you should try - for example your post here is a small step in that direction!), but that work is even lower-reward than answering those half-baked reports. To deal with low-effort, good-faith user reports, in COTS scenario, you'd hire a support/TAC person (a team, eventually). For a popular/accessible FOSS project, it is possible to have something similar on a volunteer basis: - set up IRC channel/slack/forum/mailing list for that; - display a prominent banner asking to "please try support forum first" on your bug submission page; - encourage people who want to contribute, but are not quite acing your codebase (yet), to hang around in the forum, help others.
- oefrha 6y ago
  For very popular community projects, you can indeed solve the problems by throwing some manpower at it. However, there's this uncanny valley of somewhat popular, mostly solo maintainer projects where you get a steady stream of tickets (say one or two a week) yet there's no community to speak of, so everything falls onto you. It gets pretty annoying when you have a couple of these uncanny valley projects.
philliphaydon 6y ago
> I’ve painstakingly implemented debug logs and carefully prepared issue templates yet I still get these “does not work (EOM)” (effectively) issues. I’ve gone to a few GitHub repos to report bugs only to be met with a novel length template and just left. Got no issue following a template to provide enough info to help solve a bug. But damn nothing worse than having a giant template with 20 questions.
- AnIdiotOnTheNet 6y ago
  Yeah, as much as parent complains about users not believing their time is valuable, my time is valuable too. I might not get back to you for a day or more because I have other shit to do. Generally speaking, I don't even bother to file bug reports anymore. 70% of the time my issue is already in your issue tracker, sometimes has been for years, and nothing has been done about it despite multiple users giving you the logs and whatnot you've asked for anyway. I could be all "me too" in a vein attempt to convince you you really should fix this thing, but you're just as likely to be annoyed by the complaint and further deprioritize it in your mind.
rootusrootus 6y ago
I'd like an option to pay for prioritization, or pay outright for fixes. "Pay $100 to raise the priority of this issue X points" or something like that. Wouldn't be that hard to sell to my management when we're running up against a bug that affects us directly but perhaps doesn't have a huge impact on the community at large.
- dane-pgp 6y ago
  > Pay $100 to raise the priority of this issue X points That could lead to some perverse incentives, but it points in the right direction. Some "mechanism design" / "reverse game theory"[0] needs to be applied, to turn the problem of frustrated users into a net benefit for the software, rather than escalating the conflict between developers and users. For example, if a user provides incomplete information about a bug, you could respond with a message like: "Thanks for your interest in the app and the information you have provided so far. We're currently deciding on bug fixes that will be in the next release, which should come out 3 months from now. Our decision will be influenced by the number of votes for the issue, the clarity of the bug report, and the amount of money pledged. Please head over to our forum to find other users of the software who might vote for this issue or might provide the missing information, and head to our Bountysource page to pledge a financial incentive for the fix." [0] https://en.wikipedia.org/wiki/Mechanism_design https://en.wikipedia.org/wiki/Mechanism_design
vidanay 6y ago
> I still get these “does not work (EOM)” (effectively) issues Over the last 20 years, I have received more than my fair share of bug reports just like this from well paid, trained, educated, internal engineers who's entire purpose is to support our software product. When I complain to management, I get "does not play well with others" type comments.

by oefrha 6y ago

opportune 6y ago

I understand when writing paid software with support expectations/contracts, sometimes you have to engage with the teeth-pulling exercise that is “does not work”. But why do you in FOSS? Can’t you just close the ticket and say “not descriptive enough” and move on?

StavrosK 6y ago
You can and I regularly close tickets for not following the template that says at the very top "tickets not following this template will be closed with no reply". It's even better if you can get a bot to automatically reply and close it.
- Tehnix 6y ago
  I was thinking about how one could automate this when reading. Not a foolproof way, but add a string in your Issue Templates that is required to be there, e.g. . If this is not present in the issue, the GitHub action just closes the issue with a message to please fill in the template if they wish to create an issue. Doesn't catch nearly everything, but should get some and it's easy to set up. Could be interesting to go further with the idea and maybe check if each section contains text or something like this, hmm...
  - StavrosK 6y ago
    I've seen this in repos, I'm pretty sure there are bots who implement it. I'd guess it catches more than 90% of cases, especially if you put the string at the bottom of the template.
  - a1369209993 6y ago
    Another, somewhat more underhanded trick: add a string that is required to not be there, e.g. "Please remove this line entirely.", halfway through the template, and mention it nowhere else.
oefrha 6y ago
You can. You can do anything, really, including not reading issue reports at all. But you set out to be helpful anyway, so it’s about finding a cutoff where you don’t want to help anymore. As I said, it’s simply harder than ignoring assholes. (Plus you may get a bad rep.)
hombre_fatal 6y ago
To do that, you need a healthy brutal self-respecting trait that I think most of us admire. The rest of us feel bad doing that, especially towards someone trying to use something we built ourselves that holds some measure of our own pride or even self-worth, it feels closer to obligation. So we waste our time trying to help the characters that deserve our help the least, and we learn to develop a resentful version of that trait over a period of decades.
- proactivesvcs 6y ago
  The Syncthing project will often apply this trait and you're right - it's admirable as well as pragmatic.
- pbhjpbhj 6y ago
  Sounds like a good way for someone without coding skills to help a project, bug/message triage. But then, a good bug-reporting system should be able to do such filtering? I'm wondering if detecting abusive communications is/could be part of it, bit of ML seems like it would fit, even just some Bayesian filtering might do. One could also train an NN to recognise images of the app (or simpler: OCR|grep) and require a screenshot with any submission. But I guess automated triage mightn't be the best route. It seems very much a delicately balanced people problem.
- madeofpalk 6y ago
  It's a skill probably worth practicing.
- matz1 6y ago
  Like anything else, the more you do it the easier it gets. Its not going to be instant but you'll get used to it.
- kelnos 6y ago
  I don't think you even need to be that brutal. Just have a file on your hard drive with a canned response that instructs the reporter that they need to provide more information, and how to provide it. Every time you run into a weak bug report, copy-paste that response into the issue comments. If the extra info gets provided, great, now it's a useful bug report. If not, you can close the issue, and not feel anywhere near as bad about doing so.
bxnkL 6y ago
Depends on the project. If it is governed by bureaucrats and you do that too often, you'll be accused of "not being inclusive". The modern version of "Boxer the work horse should work harder".
teekert 6y ago
Honestly sometimes the amount of things that you need to fill out just makes me use other software. I.e. kmail would never remember that I want my email threads expanded (this example is not real, the kmail devs were very helpful with minimal info in this case). Does this really require I hunt down all this info from all around the place? Sometimes I don't even know where to get the info. What helps immensely (and I saw this in the Geyser MC project), the software can produce a snippet with all info the devs want with one command, and it even exports to pastebin taking out sensitive info. If you paste such a link in their Discord it even makes an overview with syntax highlighting in the chat. That really helps a lot on my (bug reporter) side. And thus on the dev side.
- oefrha 6y ago
  If you can’t be bothered to copy a few version numbers when trying to get free support, kindly “use other software”. People providing free support usually don’t give a damn about your “taking your business elsewhere”. Moreover, - People omit things they think are irrelevant, when they are. - I print all the relevant details when --debug is on, so people just need to copy that. Some people refuse to run that and insist on submitting “does not work”.
  - teekert 6y ago
    I understand the -1, but you have to understand that to a user the choice is sometimes between: 1. Create crappy bug report and move on quickly to get things done or: 2. Do not create a bug report and move on immediately, to get things done I try to file whenever I can but when it's getting late and I want to go to bed I choose option 1 sometimes. Maybe I should choose option 2? For example, take the Nextcloud bug filing template on GitHub [0]. It's quite a long read but sure, worth the effort for free software I agree (Nextcloud is my favorite project, my life is in there, on my server)! However, I may not know exactly where these things are: ``` #### Web server error log <details> <summary>Web server error log</summary> ``` Insert your webserver log here ``` </details> #### Nextcloud log (data/nextcloud.log) <details> <summary>Nextcloud log</summary> ``` Insert your Nextcloud log here ``` </details> #### Browser log <details> <summary>Browser log</summary> ``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ``` They also want config.php, contents of `sudo -u www-data php occ app:list`, ask you to do this: Login as admin user into your Nextcloud and access http://example.com/index.php/settings/integrity/failed Also all versions: ### Server configuration \*Operating system:\* \*Web server:\* \*Database:\* \*PHP version:\* \*Nextcloud version:\* (see Nextcloud admin page) \*Updated from an older Nextcloud/ownCloud or fresh install:\* Moreover, I'm quite afraid to put my domain names or even more sensitive info onto a public website if I just copy and paste. All I'm saying is that a big button that generates everything a dev needs with sensitive stuff redacted (which should be doable here and yes maybe I should make a PR for that) will make the experience a lot nicer for the reporter and the dev. As said, the Geyser MC project [1] can do exactly this and to me it is a game changer, the whole process was fast and pleasant and it was easy to test the automated builds they made in the branch based on my issue and report back in context on GitHub. Pasting the JSON their report feature generates into their Discord channel together with your question and their ability to just !docs/something point you to relevant docs with a small command feels like magic. I found the whole process inspirational. I love all FOSS devs. You are my heroes. [0]: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C+0.+Needs+triage&template=Bug_report.md https://github.com/nextcloud/server/issues/new?assignees=&la... [1] https://github.com/GeyserMC/Geyser https://github.com/GeyserMC/Geyser
LoSboccacc 6y ago
this is extremely frustrating for the users. there's a game I used to play fairly often before updates simply broke it. like mission items were replaced with random fires floating in water. many users with the same issue reported it, and some like me even provided a save (which was never even downloaded) all such tickets were closed with "cannot reproduce" I'm not (their) tester, I don't have time to fully reproduce issues step by step, and I don't have access to a debug build anyway to figure out the bug trigger condition "does not work" is the best I can say here.
- joncampbelldev 6y ago
  Was the game free? And did the people working on the game contribute a lot of their time to it for free? If not then I can see the reason for your frustration, however it is not the same as free software being worked on (at least partly) by volunteers receiving the same lack of effort (or in signal's case nastiness) in bug submissions.
  - LoSboccacc 6y ago
    paid

Abhinav2000 6y ago

> (For the record, I got maybe a total of $10 in donations from thousands of hours of FOSS work. Actually a high profile project I worked for did receive sponsorship, but nothing went into my pocket for obvious reasons.) Can you expand on the last bit? Is it common for sponsorship not to go to the actual developers working on the project and getting eaten by middle layers of bureaucracy?

oefrha 6y ago
I never saw a dime and never looked into spending details, but to the best of my knowledge, sponsorship money largely went to hardware for infrastructure; then some went to sponsoring physical meetups, e.g. reimbursing travel expenses of team members who attended FOSDEM. It’s not a lot of money so if everyone gets paid I suppose it would only be a token amount.
- Abhinav2000 6y ago
  Thanks!

saargrin 6y ago

you are a true hero :)

imtringued 6y ago

You need a consistent process that you can point your users to. If they don't follow the process then politely explain that this will save time for both parties.

oefrha 6y ago
I do. It’s in the issue template, it’s in the wiki (pointed to by issue template), and commonly seen error messages may even point to the relevant wiki page. People who don’t care don’t care.

asiachick 6y ago

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)

YorickPeterse 6y ago

Over the years I've learned there's a class of users that simply don't read. Example: for GitLab we stopped using the repository that used to host the code for GitLab CE. All issues were closed, and when you create a new issue there's a template active that basically says "Don't create issues here". In spite of that, people still create issues here, and in some cases don't even bother changing that template.

enriquto 6y ago
This sounds like an UI problem. Why can't the system just disable the issue creation button?
- kubanczyk 6y ago
  Yeah. It's literally one checkbox lacking on GitHub. So (1) Scrape the old, closed issues to a static website, link it from README.md. (2) Disable Issues in GitHub's repo settings. Part 1 is somewhat complicated, because issue-to-issue linking.
smeej 6y ago
I've spent more than a decade in customer/user-facing roles, and that class of users is actually "almost all of them." But it's worse than that. Most people do not have the reading fluency to read more than a few words in a sentence without getting frustrated and confused. If your work peers and social groups consist of the 3-5% of people who aren't in that category, it can be easy to forget that. Any time you can make something's function clear with one or two words and design, opt for that over explanation.
- BurningFrog 6y ago
  And this is why UI/UX experts are so valuable in software projects!
- crznp 6y ago
  If "almost everyone" fails some expectation, is the problem with the people or the expectation? The average user might not be super invested in the application, they just know that something doesn't work, which is frustrating. If their only outlet for that is a bug report, the developers get overwhelmed with bad bug reports and users get the expectation that the developer is going to fix all their problems for them. If the outlet is a feedback form instead, maybe the user can feel listened to in a small way and move on. The developer doesn't have to sift through a bunch of issues, they can just follow up if there seem to be any hot-spots that are causing a lot of frustration.

sampo 6y ago

Could issue boards have volunteer community moderators, like Reddit and StackOverflow have?

raxxorrax 6y ago

I think a problem is the social integration of sites like Github (I assume you have your project there). Traditionally low-effort questions were filtered out because many users didn't want to get into the trouble of contacting developers directly. Although it wasn't unheard of, but there was probably significantly less noise.

nousermane 6y ago

What you are describing is a perfectly typical (and expected) behavior for a user of a commercially-licensed library/server software. Many developers/admins use both FOSS and COTS, and feel the same low-effort interaction with upstream is okay in both cases. It's possible to educate a small number of your users (and to a some extent, you should try - for example your post here is a small step in that direction!), but that work is even lower-reward than answering those half-baked reports. To deal with low-effort, good-faith user reports, in COTS scenario, you'd hire a support/TAC person (a team, eventually). For a popular/accessible FOSS project, it is possible to have something similar on a volunteer basis: - set up IRC channel/slack/forum/mailing list for that; - display a prominent banner asking to "please try support forum first" on your bug submission page; - encourage people who want to contribute, but are not quite acing your codebase (yet), to hang around in the forum, help others.

oefrha 6y ago
For very popular community projects, you can indeed solve the problems by throwing some manpower at it. However, there's this uncanny valley of somewhat popular, mostly solo maintainer projects where you get a steady stream of tickets (say one or two a week) yet there's no community to speak of, so everything falls onto you. It gets pretty annoying when you have a couple of these uncanny valley projects.

philliphaydon 6y ago

> I’ve painstakingly implemented debug logs and carefully prepared issue templates yet I still get these “does not work (EOM)” (effectively) issues. I’ve gone to a few GitHub repos to report bugs only to be met with a novel length template and just left. Got no issue following a template to provide enough info to help solve a bug. But damn nothing worse than having a giant template with 20 questions.

AnIdiotOnTheNet 6y ago
Yeah, as much as parent complains about users not believing their time is valuable, my time is valuable too. I might not get back to you for a day or more because I have other shit to do. Generally speaking, I don't even bother to file bug reports anymore. 70% of the time my issue is already in your issue tracker, sometimes has been for years, and nothing has been done about it despite multiple users giving you the logs and whatnot you've asked for anyway. I could be all "me too" in a vein attempt to convince you you really should fix this thing, but you're just as likely to be annoyed by the complaint and further deprioritize it in your mind.

rootusrootus 6y ago

I'd like an option to pay for prioritization, or pay outright for fixes. "Pay $100 to raise the priority of this issue X points" or something like that. Wouldn't be that hard to sell to my management when we're running up against a bug that affects us directly but perhaps doesn't have a huge impact on the community at large.

dane-pgp 6y ago
> Pay $100 to raise the priority of this issue X points That could lead to some perverse incentives, but it points in the right direction. Some "mechanism design" / "reverse game theory"[0] needs to be applied, to turn the problem of frustrated users into a net benefit for the software, rather than escalating the conflict between developers and users. For example, if a user provides incomplete information about a bug, you could respond with a message like: "Thanks for your interest in the app and the information you have provided so far. We're currently deciding on bug fixes that will be in the next release, which should come out 3 months from now. Our decision will be influenced by the number of votes for the issue, the clarity of the bug report, and the amount of money pledged. Please head over to our forum to find other users of the software who might vote for this issue or might provide the missing information, and head to our Bountysource page to pledge a financial incentive for the fix." [0] https://en.wikipedia.org/wiki/Mechanism_design https://en.wikipedia.org/wiki/Mechanism_design

vidanay 6y ago

> I still get these “does not work (EOM)” (effectively) issues Over the last 20 years, I have received more than my fair share of bug reports just like this from well paid, trained, educated, internal engineers who's entire purpose is to support our software product. When I complain to management, I get "does not play well with others" type comments.