Comment by 0xbadcafebee

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.