> For me personally, this is an area where I struggle the most. My emotions get the best of me, because all I can think is: why didn't this person take the time to read and fill out the issue template? Or, in cases where bugs are user errors that could be resolved by just reading the documentation, all I can think of is: I spent this time gifting this user some software, but they can't even read the README before filing a bug report?
This resonates so much. Users who blatantly waste your time despite multiple cues steering them towards actionable bug reports are worse then trolls or haters IMO. (I use issue templates, with all caps and explosive emojis, and I even put specific actionable wiki links in error messages, but some people still insist on opening barebones “doesn’t work” bug reports. Or duplicates. People open duplicates when there are like three open issues in total and one is clearly the same issue as theirs. What the hell?)
With trolls or haters you can simply drop the ban hammer, easy. With this kind of high-maintenance users, it’s hard to decide whether you should waste time helping them, or simply refuse action until they get their act together.
> It can be maddening. But that's emotions for you. They certainly aren't always rational. The documentation could probably be clearer. Or the user could have just missed that part of the documentation. Or the user doesn't have experience maintaining FOSS projects or filing bug reports and maybe does not know how to provide an easy reproduction. These are all perfectly reasonable things to have happen, and it's why I do my best not to let my emotions get the best of me. While the way I feel is important, empathizing with the person on the other end of the wire is important too.
Honestly it’s hard to empathize with users who can’t follow “run command with --debug, post entire output” or who don’t bother to read anything when the error message clearly says “here’s a wiki article for your specific error, read it before reporting a bug”.
Until recently I was working for a large startup where I would see this kind of behavior constantly. Join a inter-team developer-support channel, send a "I'm seeing errors from your service" and wait for you to respond. One time I ended up chasing the error back to a deployment done by the person sitting next to the reporter.
We also had a helpdesk-style support chat for our developer tooling, complete with a bot that would respond to common error messages with links to solutions and people would STILL directly message engineers that supported the tools asking for help on trivial build issues or inability to use command line tools.
It was sort of baffling to see, its not like its any quicker than doing the right thing, it was simply people being lazy. Some of it's an Eternal September, too, I think.
This resonates so much. Users who blatantly waste your time despite multiple cues steering them towards actionable bug reports are worse then trolls or haters IMO. (I use issue templates, with all caps and explosive emojis, and I even put specific actionable wiki links in error messages, but some people still insist on opening barebones “doesn’t work” bug reports. Or duplicates. People open duplicates when there are like three open issues in total and one is clearly the same issue as theirs. What the hell?)
With trolls or haters you can simply drop the ban hammer, easy. With this kind of high-maintenance users, it’s hard to decide whether you should waste time helping them, or simply refuse action until they get their act together.
> It can be maddening. But that's emotions for you. They certainly aren't always rational. The documentation could probably be clearer. Or the user could have just missed that part of the documentation. Or the user doesn't have experience maintaining FOSS projects or filing bug reports and maybe does not know how to provide an easy reproduction. These are all perfectly reasonable things to have happen, and it's why I do my best not to let my emotions get the best of me. While the way I feel is important, empathizing with the person on the other end of the wire is important too.
Honestly it’s hard to empathize with users who can’t follow “run command with --debug, post entire output” or who don’t bother to read anything when the error message clearly says “here’s a wiki article for your specific error, read it before reporting a bug”.