5 ms·
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
by sagichmal 6y ago
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.
- blueflow 6y agoYes, thats how ddevault is.
- forgotmypw17 6y agoI see a lot of this in the software world, from both reporters and maintainers. It will motivate me to de-invest in a project if I see it more than once, e.g. Chromium and Firefox. However, after scouring the entire thread, I didn't notice anything like that in the linked thread?
- tester756 6y agowhere is he actually "rude" or acts like "and an air of expectation, as if the maintainers owe him a solution"?
- myspy 6y agoHe 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.
- forgotmypw17 6y agoimo, 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.
- strenholme 6y agoWith 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.
- forgotmypw17 6y agoit 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.
- h_anna_h 6y agoHe is actually a poster here. https://news.ycombinator.com/user?id=ddevault https://news.ycombinator.com/user?id=ddevault I don't see anything wrong with what he posted in that thread.
- oblio 6y agoHis initial bug report? "I have hardware from 40 years ago, your software doesn't work, please fix?" If I would have seen that I might have replied: "Patches welcome" :-)
- h_anna_h 6y agoHe 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.
- ddevault 6y agoI 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: https://l.sr.ht/2DEG.png https://l.sr.ht/2DEG.png But I don't think that this thread was such a case.
- asddubs 6y agoI 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
- marcan_42 6y agoI 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.
- nyadesu 6y agoSeems fine to me, to be honest
- indymike 6y agoThere 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.