Show HN: Most users won't report bugs unless you make it stupidly easy

> What other industry relies on its customers as implicit developers?

I would say most of them. To list a few:

- restaurants (almost all of them will send you feedback surveys these days, they also rely on you to tell them if they, for example, cooked your steak to the wrong temp)

- property maintenance (again, feedback surveys)

- auto mechanics (if the thing they fixed is still broken, a good mechanic wants to know)

- doctors (they rely heavily on YOU to tell you what wrong with your body)

- democratic political systems (when working correctly)

- road infrastructure (the city won't fix potholes nobody is reporting, and they won't do anything about badly tuned traffic lights nobody complains about)

- vaccines and medicine (the testing phase may not uncover every possible single side effect, they need recipients/users to report those if they happen)

(Please nobody come back with cynical takes on how these aren't helpful in their specific case/location, that's clearly not the point)

none of these are bugs, they are complaints about specific date/time/incident.

restaurants

undercooked steak is not a bug unless every single steak on every single day is undercooked

property maintenance

same thing (and weird example)

auto mechanics

also not a bug, bad part, mechanic who didn’t get laid the nite before… not bugs…

doctors

not sure how to even respond to this… :)

democratic political systems

would be nice :)

road infrastructure

wear and tear :)

The unfortunate situation is that bugs in modern software just seem to… show up, as if their appearance is an ongoing maintainence issue rather than the outcome of something somebody on the development team did.

But, anyone who took the time to write bug-free code went out of business decades ago.

I love this, and I'm so glad it has resulted in more people filing bugs. That said, there is a larger problem going on here that has yet to be addressed by the software industry as a whole. And that is that "bugs" (and "filing" bugs) is a very complex thing. It's not just one thing, it's many, many things. And until we face that and provide a holistic solution for "it", it will continue to be an existential problem.

Here's a selection of the different kinds of complexity with "bugs":

- Type. Is it a backend or frontend bug? A network bug or an infrastructure bug? An internal or external bug? Is it a "not considered a bug" bug? Is it a bug in documentation, training, intuitiveness, etc? A product- or feature-specific bug? A location-specific bug? A user-specific bug?

- Context. Is the user even capable of giving you enough context and information for this bug report to be usable? If so, is automatic? If not, will the user simply give up reporting when this becomes difficult?

- Communication. How does the user even report a bug? (I regularly try to file bugs with every tech product I use - because they are constantly riddled with end-user bugs - but I spend hours trying to dig up some way to contact the company to report the bug, and when I finally can contact someone, they refuse to even take my bug report, because it's not one of the read-from-the-script-customer-service responses/actions. And if the user does eventually get in contact with the company, is the developer (or anyone else) even capable of communicating with this user to get more information or inform them of a fix?

- Visibility. Quite often, users will experience bugs, and maybe one report comes in about them. This is then captured by customer service or someone else, and maybe they file a ticket. But then for each subsequent request, they just tell the customer they will record it and then.... don't send it to anyone, because they've already sent one such bug and assume it's being fixed. So the developers have no idea how often this bug is actually happening. Often when bugs are reported the devs aren't informed at all.

- Impact. Is it just affecting a single user, once or twice, in a niche setting? Is it affecting the same user all the time? Is it affecting a subset of users? All users? Is it affecting all users, but core functionality still works? Is it significantly affecting core functionality? Is it affecting core functionality but there's bigger issues going on so it's actually less of an impact? Are the developers even capable of understanding the impact? (how many of you know exactly how much each specific function affects the business?)

- Prioritization. We all have ticketing systems full of hundreds of tickets that sit in the backlog never to be fixed. They're annoying, or difficult, or unsexy, or they're not a new feature. Sexy bugs get prioritized, unsexy bugs sit in the trash heap.

- Fixability. Even if all of the rest is provided for... how difficult or easy is it for a developer to fix? Is the developer capable of contextualizing it and making use of the information? Do some of them have difficulty reproducing it, while others don't? Do they have all the training needed on all the systems involved in order to effectively triage/investigate/troubleshoot? Are they given dedicated time each development cycle to fix bugs? Are they even able to track down who is responsible for "fixing" the bug, what with the modern mess of interdependent microservices and siloed development teams? Will they be implementing regression tests to make sure it doesn't come back? Are you rewarding them for this work, in addition to the rewards for "sexy work" (new features implemented, cost saved)?

Yes, getting users to file more bugs is fantastic! But that is quite literally the tip of the iceberg.

Don't forget all major OSS repositories using a stale bot to close any issue regardless of how many people reported it or how serious it is. Close and lock at times. Yikes.