A production ByteBuf leak took me from Netty logs to a fix shipped by Microsoft in a few weeks. Here is the step-by-step process I use to report bugs so they actually get fixed.
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.
Do these kinds of templates actually help against really bad submissions, though
Þ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 TERMINFO is 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.
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.