A Week of Bug Reporting
tratt.net
tratt.net
Most people don’t directly use open source, and reporting bugs in closed systems is rarely rewarding.
With the issue trackers that are common in open source, a bug reporter gets to watch the bug report’s lifecycle.
They can see what the developer – and others – think about the bug report. Is it a real bug? Was it reported previously? Is it worth fixing? Does the report contain sufficient detail to reproduce it?
With enough time, the reporter will learn if the bug is fixed or discarded or ignored. At the outer loop, they can become better reporters of bugs by seeing this play out enough times.
In contrast, bug reports to a typical end-user application go into a black hole from the moment they’re submitted. Even if said bug is eventually fixed, the reporter will be none the wiser about whether their submission was even looked at, let alone triggering the fix.
True, but not always, I've heard PMs saying: "this was a user-submitted bug", meaning you better fix this ASAP.
But yes, for the most part they don't like it. I recall reporting a bug and then they obfuscated their SPA bundle.
Funny enough, today I spent like an hour thinking: should I report this, should I ever report bugs at all. It was a P0 but I didn't report it, and I noted it as my first time considering giving up on my career.
Last week I reported a list of medium-bugs and I ended with: "I'm not sure if you'll ever read this, so I'm not adding more details that could help you debug, but feel free to reach out…" They responded: "We will share this feedback with the appropriate team. No further action is required on your end. Your ticket 124443 is solved. Please rate us!"
There are certainly developers with a practice of triaging and action user-submitted reports, but unfortunately it’s opaque to the one who reported it.