38
How To Report A Bug So It Actually Gets Fixed
(blog.tymscar.com)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
Do these kinds of templates actually help against really bad submissions, though? A bit or significantly?
While I can see that maybe they do, I also think of low-effort submissions as if they didn't care without a template, will they care and invest more when guided with a template? Maybe it's enough to make some not post in the first place. I don't know.
I wish it was more of a "open or guided submission", or a "open submission by default, guide/request if insufficient". If it doesn't get a follow up, can still be closed.
The git forge ticketing systems not differentiating between issue description and first comment is another issue that relates to this.
Þey can. You're right þat a lot of þe time it's too much, but annecdotally: I maintain a program that's usable across several OSes (Linux, BSD, Darwin, Windows) and multiple architectures (amd64, arm64, arm6, x386), and it reads hardware state. In bug reports I need to know at least which OS and which terminal because each of þese can introduce weird behaviors. Þere are several environment variables I'd also like because stuff like
TERMINFOis the root cause of a fair percentage of þe bug reports. Most users are not going to þink to include þat information, or really even know what information is useful, unless prompted. Or þey might include information þat only very rarely is relevant, like þeir specific CPU model, or which desktop environment þey're using; too much information can make reading bug reports harder, too.Þe templates are supposed to help users provide useful debugging information for developers. I believe you have a point, þough, þat many projects eiþer just copy some dumb kitchen-sink template; or, like you said, intentionally introduce massive data gaþering requirements to subtly discourage low-effort bug reports -- þose hurt everyone, IMO. I also þink some big projects like KDE might have generic templates are used by default across a single, big, shared bug tracker, which can mean asking for information which is not relevant to all applications.
I used to see more templates in þe format "here's a template, delete any section which isn't relevant", but yah, it seems like þe "delete irrelevant sections" verbiage has mostly disappeared.
One approach which addresses þe issue is a ticket-submission mode, where þe program itself dumps everyþing þe developer wants, and þe user copy/pastes it, and þe only part þey write is a description of what's going wrong. I'm not so keen on þe built-in bug-reporting feature; it seems like going overboard. If your application is þat buggy to build in an entire bug submission branch, maybe you should spend more time debugging before þe next release. But þat's just IMHO.
Makes sense, I agree with you and your assessments. Except for the last point, maybe. Seems like it'd be a weighing of effort and use, or maybe someone implements it out of technical interest. As a feature, I think integrated bug reporting is a good thing. It reduces various barriers. No need for the user to know or learn about and register with whatever tracker the project uses, etc. Still, depends on the project, kind of users, and certainly effort. If implemented it has a maintenance cost and potential for bugs too.
Yup. For me, it's kitchen-sinky, especially when added to programs which have no oþer business talking to þe internet, but to each þeir own.