The thing that strikes me about this issue is how unhelpful and, well, rude the author is. Terse, minimum viable answers to questions, no contextual detail even when it is obviously needed, and an air of expectation, as if the maintainers owe him a solution.
He did not say "please fix". He also explained the exact issue that he encountered on the exact hardware that he used. Simply saying "patches welcome" would not clarify whether you are interested to help this person to figure out what the issue is.
There was nothing rude in the comment. It stated the problem: fish wasn't working in a VT220 (you have to read the title of the ticket to understand it). The rest of ddevault's comments were actually quite positive and friendly and there was zero entitlement. There was a lot of nostalgia.
I am the author of this issue and I don't really know what you're talking about. Terseness is something I value in bug reports as a maintainer myself. I don't want to read someone yarning on about the breakfast they were eating when they encountered a bug. I want them to tell us everything they know, and then nothing else. The pattern I did here - create a record of the bug with what I know, then investigate it on my own and update the discussion when I have more information or a solution - is also something I like to see as a maintainer.
Rude, entitled users is definitely a problem maintainers have to face. Here's a better example:
I think you were excessively terse. Nobody wants to know what you had for breakfast, but given the nature of the bug, clearly staring and restating the state of LANG, TERM, any intercepting terminal emulators, and how you were running this (on a serial try), would've helped narrow down the bug.
Your initial report started with an incorrect premise - fish does not work on a vt220. The real bug ended up being that fish does not work on Linux serial ttys. That's fine - we all make these kinds of mistaken assumptions about bugs - but it's here where mentioning all the details helps.
For example, without info about how it's hooked up via serial to a getty, it's unlikely someone unfamiliar with these setups would think about the possible consequences of that. And without mentioning the state of TERM, the bug is ambiguous: does fish not work on a physical vt220 with some settings, or does fish not work with TERM=vt220? Those are two different problems.
Excessive verbosity is fluff, but excess brevity leads to information loss. Some redundancy is required to ensure the meaning gets across. This is human error correction.
You weren't rude or entitled, but everyone on that thread, yourself included, displayed less than ideal bug reporting and handling skills. Things could've gone much more smoothly.
I don't think you were rude in the bug report, but I think there's an issue where if something is described with lots of brevity, even if accurate, it's hard to know if what was said is really what was meant, since there's enough bug reports that aren't careful about their language that you can't really trust someone when they just say "it just hangs". So in that case a more detailed description/picture/whatever of what exactly the error looks like is helpful even if technically it can be described in one sentence
He refers to the initial issue text without anything there. I know that it‘s best to create an issue with context and description. The approach of doing that somewhere in the thread is new to me.
imo, it,s better to make note of an issue than not at all, to get the ball rolling. the first post provided enough info to begin investigating.
tbh, few things annoy me more in foss world than a mandatory 20 questions form and process when reporting a bug (or feature request) which requires much less to communicate clearly. i don,t think that,s user friendly at all, and in me opinion it is shifting qa,s work onto the user.
With FOSS, the economics are very different than with paying customers. It’s fair to ask a FOSS user to go to a lot of effort to file a bug or request hand-holding support; the developers are not getting paid, so asking to user to work harder to make life easier for the developer is perfectly fair.
it might be ,,fair,, but it,s also a failure to be addressed, a missed opportunity to improve the software, which turns into a poor experience for the user.
i think the missing piece is grassroots support for individual users by the technically literate elite.
