It’s so important to treat companies individually instead of just according to some blanket impression of the world. Individual treatment means good companies benefit and grow, while blanket treatment actually actively rewards bad behavior: a company that invests in quality will bear the cost while you share the benefit with the competition, while a company that treats you worse will reap the savings while you take out your frustration on the competition, too.

Yep. That has always been the general industry sentiment [1]:

> Here’s another bug that’s not worth fixing: if you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn’t even use large files. Well, don’t fix it. Worse things have happened at sea. Similarly I’ve generally given up caring about people with 16 color screens or people running off-the-shelf Windows 95 with no upgrades in 7 years. People like that don’t spend much money on packaged software products.

[1] https://www.joelonsoftware.com/2001/07/31/hard-assed-bug-fix...

I think I've reported bugs to Bloomz (the awful communication app my school uses), jpmonette/feed (the node/typescript RSS feed generation library), and I think at one point I reported one to Newsblur, and they all got fixed.

Now the linux-industrial complex is a special case, if you are a software engineer and know how to isolate a problem and submit a great bug report you will often hear from people who will say you sent them the best bug report all quarter. It helps if the team is working with web tech, younger, more diverse, and never heard of the GPL.

As a submitter, you can decide to invest in someone's detailed bug report form, including attaching screenshots, etc., maybe taking an hour or more, and derailing the work mental mode you were in.

After that work, what you learn most likely happens next is one of the following:

* Silence.

* "Yes, that's a problem." Then silence.

* 6 months later, automated email saying that this bug is automatically closed, due to inactivity.

* 2 years later, automated email that they've done a new release, so they've decided to throw away all open bug reports. But if you still find the bug in the new version, you can file a new bug report, they graciously offer.

* "We know about that bug, but we aren't going to fix it." For reasons you don't understand. And if there's a cultural mismatch, the tone can come across as hostile or disingenuous, besides.

* "This is a duplicate of bug X." It is not.

* Closes the bug report suspiciously, perhaps for optics or metrics.

* (Silence FAANG Special Edition: A high-profile bug report, on which tens or hundreds of knowledgeable people are adding on, for years, all saying this bug is a huge problem, and many asking in the bug report comments why is nobody from the FAANG even acknowledging this bug report in their own bug system.)

Suggested practice: If you ask others to invest in reporting bugs (by having that bug report form there), then follow through in good faith on the bug reports you receive. (At least on the bug reports that seemed reasonable, and that invested effort in your process.)

Making simple, useless bug reports is easy and it will always be the easiest. Also the "my neighbour spies for the government" types will anyway always be the most motivated ones. There is no way to make it hard for "bad" reports without making it harder also for useful reports (barring some obvious cases of bots, ip filters etc, which are not what is discussed here and are a general problem not just for bug feedback). By trying to reduce the noise, you also reduce the signal thus get a worse SNR.

The specific tool is smart in trying to increase the signal. If you make it easier for users to add some useful context, MAYBE you get more users actually giving you sth useful, maybe even users who otherwise would not bother to add anything more useful than "it does not work".

I use software that recently made much simpler to make bug reports and add context, and they say they actually receive much better bug reports after. And most importantly, the users actually see that the bugs get fixed, which motivate them to make more, and more detailed, bug reports. Imo getting bugs fixed (and maybe even recognise the users' contribution in reporting them) is the best way to get good bug reports. Honestly, from my user's perspective having my feedback taken seriously is the best motivation for me to continue submitting reports. Because, honestly, sometimes bugs come up in complex situations that may be tricky to understand/reproduce, and it is hard to understand what context is relevant. I am not usually motivated as a user to spend like 20 minutes figuring out exactly how to reproduce a bug, but if I see that the company/engineers actually care and try to make it easy to me to report to them, I may actually do it.

Yes you are gonna have bad interactions also (and remember people have their own jobs/lives/not enough time to always engage with you the way you may want them to in providing feedback), but the point is to increase the good/useful interactions (compared to them), not decrease interactions in general. Unless you do not care much about bug reports anyway, that's also fine.

This so much.

I can't tell you how often I've seen someone trying to get tech support on something say "When I load the program, I get an error" but don't even say what the error says. I understand that most people have never worked a QA job and so don't know how to write a good bug report, but certainly I would expect someone to copy/paste the error message.

I however wouldn't shorten/transform reports with an LLM, or make spammy reports inaccessible. Just doing the semantic grouping for escalation. It's true you're getting free work from your users, and the human factor is pretty important here, even if an LLM might sometimes misinterpret it.

It cuts both ways. Guess what's one of the most popular format for apps and webpages to report failures to the user?

"Oops. Something went wrong."

Not exactly overflowing with useful information, either.

Sure, the system is probably logging the fault internally, and is always collecting metrics that help with contextualization later. But the system and its owner aren't usually the ones most affected by any given bug - it's the user who is. The user who's now worrying whether it means they're about to lose the time and work they put in the current session, or whether the app just ate their money (failures half-way through payment processes are the cutest, aren't they?). They don't know - maybe the "Oops!" was just benign, or irrelevant. Then again, maybe they've already lost it all 10 minutes ago - back when the previous "Oops!" briefly flashed to gently inform them that the service's back-end tripped over itself and died - but they won't discover that until later, at which point they'll be neither able nor willing to make a proper bug report.

Point being, if one sees their users as being 5 years old (but with parents' credit card in hands), one shouldn't be surprised to only ever get a kindergarten-level error reports like the ones you mentioned[0].

This is not just me complaining on a tangential issue - I believe showing specific and accurate error messages improves the ratio of useful error reports. It's not a full solution, but it's a step in the right direction. Treating them as partners, instead of a bunch of brats you have to put up with until they complete the payment, makes them more willing to reciprocate; giving users means to contextualize their experience allows some of them[1] to understand what's going on, and gives them something useful to put in the report too.

That, or I guess nowadays you can also keep the "Oops."-es, double-down on telemetry, and feed the metrics to a SOTA LLM to identify and interpret failures for your engineering/operations team, which we all know has neither time nor patience to do it.

--

[0] - "Page doesn't work" is the adult version of a kid suddenly starting to cry for unclear and possibly non-specific reason.

[1] - Obviously, not all, or even most. Software is complex, most users still behave as if half-drunk and unable to read, etc. Still, even 5 year olds can comprehend basic words and identify patterns. Figuring out that "could not connect to payment gateway" is serious, that "failed to write [blah blah tech terms]" that happens at random is probably not, etc. is within the cognitive reach of most users.

For every user who reports a clear, reproducible defect, there 10 others who report non-reproducible issues, who conflate features with bugs, who ghost, who use issues for support or questions, who are just angry about something and think you're an idiot, who report (since fixed) defects against old versions, or who report duplicates to existing issues. It's a very noisy channel.

It can lead to a crappy outcome for both the reporter who earnestly tried to help and for the developer who wishes they had the time to carefully address every reported issue but just don't.

Sometimes, all that's feasible is making time to triage/acknowledge each issue in a reasonable timeframe and to be forthright about its prioritization.

As an aside, I find your opinion that "if I give you my time in the form of a bug report, the least you can do is give me your time" to be common. We rarely have the right to demand another person's attention, though. Especially with respect to non-commercial open source hobbyist maintainers.

They had a public facing jira open, where people could file bugs and what not about the viewer (the client) and the world (the server).

You didn't need some special account or something like that, just your normal Second Life account was enough to get access to that one.

Drawback was, you were able to see what happens when filing bugs is easy. Of course, many people used it to file real bugs but also complained about stuff not working like they expected (or how it should work according to them, which brought other people up against them and so on...in the end you were able to read the latest drama here and there, right in the jira entries).

Although, to be honest, i thought it was an awesome idea, but you when you open up an easy way for people to report bugs, you need an easy way to explain what bugs are and what not. :)

The number of hardware and software combinations are impossibly large, so you're unlikely to be handling everything perfectly if the application is doing anything complicated.

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)

I've worked with people who uttered this phrase many times. You really should put this on your CV because it's an incredibly helpful indicator of character trait.

I also just got a first response about a bug I reported 5 months ago,

It really depends on the author

It is an approach, for sure.

See, if you rely on a vendor, then you need them to survive. It’s a parasite-host relationship. You need to tell them what you need, and oftentimes they will bend the roadmap in favour of the most demanded features. Alternatives:

- They choose their most amusing feature,

- They choose the most lucrative feature among the new possible markets while ignoring all bugs, which is the most rational way to address bugs unfortunately,

- You don’t tell them, they don’t improve, they die / they triple the price of the product by lack of audience, and you have to migrate your data to another product.

A) only pay for perfection and

B) experience zero friction or cost in moving services?