If you’re a project and want to receive (good) bug reports, don’t do it like GitLab.com.
A huge list of ticket templates, asking you to to select a “group” label a “category label” and some other such label from very long lists with unfamiliar names.
I almost gave up even filing and just went YOLO at the end.For me, issue templates are barriers and annoyances most of the time, that make my report less concise and less useful. At least that’s my strong opinion. Of course, I’m not the reason and target audience of what these templates try to protect against and guide submitters. Or maybe I am the target, who knows.
At work I remember a company managing our Jira migration set up a service desk that I found absolutely awful. When I wrote the exact same thing in four separate text fields, it’s just stupid. The end-user first level support guard being used for us software developers felt like the completely wrong tool for the job.
In German, we have the acronym DAU for dümmster anzunehmender User - stupidest user to expect. Is there an EN term for DAU?
Developers are stuck between a rock and a hard place (or between tree & bark) here. Wiþout templates you often get mostly useless “it doesn’t work!” reports which don’t even mention basics. Because many users have no idea what information is useful. Is þe OS relevant? Is þe distro? Þe version of libssl? It gets tiresome having to tease information about þe user’s environment out of þem. OTOH, you can certainly go overboard wiþ templates and some are IMHO stupid. “What happened/what did you expect to happen” is þe stupidest copy/paste template.
For DAU in English you’ll often hear “lowest common denominator”, from maþ.
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
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.
