
They Might Never Tell You It’s Broken - ingve
https://pointersgonewild.com/2019/11/02/they-might-never-tell-you-its-broken/
======
adrianmonk
I saw this happen once at work. An engineering manager scheduled a meeting
with an internal client to establish a better relationship between developers
of an internal tool and the users of it. No specific agenda items, just
general improvement of the communication. He invited everyone from both teams.

He went through some material that he thought mattered. People found that
kinda useful, but then there was an open Q&A. One of the users asked when the
dev team was going to fix the bug where if you enter data in one place, the
system acts like it saved it but silently discards it, so you have to go
elsewhere in the UI and do it there as a workaround.

The crowd reaction was interesting. One half nodded in agreement; the other
half was surprised and perplexed. The bug had been around for literally years.
100% of the people on the client team were familiar with it (probably from
being bitten by it personally). 0% of the dev team were familiar.

Other than don't assume and if you see something say something, I guess the
moral here is that the manager's instincts were right on. That meeting needed
to happen. There was some kind of communication barrier that needed to be
broken down. I'm not sure, but maybe the client felt the developers were
unapproachable or unreceptive or that the organization didn't view them as a
priority.

~~~
nemosaltat
-Across at least 4 versions of iOS, I’ve found that if you start the Personal Hotspot while the Wi-Fi is/was recently connected, potential Wi-Fi hotspot clients won’t be able to connect.

-My personal workaround is to turn off Personal Hotspot, turn of Wi- Fi, then turn Personal Hotspot back on. This produces a prompt that asks if I want to `Turn on Wi-Fi` or use `Bluetooth and USB only`. Selecting `Turn of Wi-Fi` resolves the issue.

-I’ve been doing this for years. I never thought much of it, until at the end of a recent haircut- My stylist was once again fumbling with her Clover card reader. Usually when this happens, I just pay cash. This time I asked if I could take a look. She explained that the Clover gets internet from her iPhone, but occasionally and inexplicably it disconnects. She said sometimes rebooting the iPhone resolves the issue.

-I showed her my work around, and she sheepishly admitted that she’d probably forget. She came to the US as a refugee from Vietnam- age and language aren’t making this any easier. I ended up using stitched together, marked up screenshots to save PDF instructions for her.

-Until last week it never occurred to me to report this “bug” to Apple. I can’t even remember how I arrived at my workaround.

~~~
Nextgrid
Bug reporting should also be quick & easy for it to be effective. The Apple
bug report process isn't the quickest. It doesn't help that minor
bugs/usability issues like that never get corrected (from my experience) so
I've personally given up.

I wish they'd repurpose the stupid "shake to undo" to report bugs instead and
make it automatically start screen recording, allow you to reproduce the bug,
edit the video to hide any PII and then upload that along with system
information.

~~~
jakear
The sceptic in me says that the cost to go through all those reports, even if
they were just text as opposed to video, far outweighs the potential benefit
they’d get from fewer bugs in the OS. I don’t think very many people will
decide to switch to Android based on a buggy iOS experience.

~~~
dannypgh
Surely it's a computer, and not a person, handling triage of bug reports. At
Apple's scale, bug reports are easily ignorable until there's multiple.

------
qwerty456127
> Most of the time, if it doesn’t work, they won’t report the problem. There
> are a few reasons why this might be:

There is one more reason the author didn't mention as it doesn't apply to his
case: people don't want to sign-up for new accounts in every bug tracker just
to report a single bug. If it's GitHub and the issues tracker is enabled -
it's ok for most of the people as they probably have a GitHub account already
(but I still believe there are people who don't). If it's a BugZilla instance
(which means you have to sign-up), let alone a mailing list (which most of the
people don't even know how to use) - that's a serious obstacle for bug
reports. If you want all the bugs to be reported - declare this a visible way
(and promise you won't respond like GtFO and RTFM) and make it easy, e.g. by
accepting bug reports via plain e-mail (a couple of alternative ways like
Twitter and/or Reddit won't hurt).

~~~
unlinked_dll
If anyone is reading this from Apple or Jetbrains, take notes. Your bug
trackers are obnoxious to log into and use.

~~~
qwerty456127
The Jetbrains buck tracker is not that bad and it is worth registering at
because the fact you have found a bug in a JetBrains product suggests you
probably are in using it seriously enough to find more soon (there are many),
and there are no real alternatives to Idea anyway so you are doomed to keep
using it if a text editor or a less smart IDE is not enough for you.

~~~
unlinked_dll
There are plenty of alternatives (I primarily use CLion).

The issue is more that it takes more time to log in, load the issue tracker,
search to see if it's already there, create a new issue, wait around for a
response email, record/send the logs, and then wait to have them tell me they
couldn't reproduce the bug.

Just like with Apple I stopped reporting bugs to JetBrains, because with most
products I can send an email with reproducible steps and that's the end of it.
With them it's a whole process.

And JetBrains, why is the default notification for tracking a bug/feature
request sending an email for _every person who upvotes it?_

~~~
enobrev
> why is the default notification for tracking a bug/feature request sending
> an email for every person who upvotes it?

This is incredibly frustrating. I commented / followed a bug a few years ago
that they clearly will never fix (start-up stealing focus on Linux), and have
received tens, maybe hundreds of emails from upvotes and "me too" comments.

Fix, Wontfix, anything from the team, I'm in, but wtf would I ever need to
know about upvotes?! You could send me a monthly stat email on my bugs. That
would be great, actually. It's weird to see things that annoying from a team
that makes such a great software suite. Almost as annoying as having my IDE
steal focus upon start-up.

~~~
unlinked_dll
The one for me was a Ninja exporter for CLion. Ironically, I found out that
the feature was recently added because I saw a post from them on LinkedIn. Not
the bug tracker.

------
gwern
I ran into this a few months ago. To show off my StyleGAN-generated anime
faces, I made
[https://www.thiswaifudoesnotexist.net/](https://www.thiswaifudoesnotexist.net/)
to load random samples. It went viral in China. After about 450,000 unique
people visited (according to my Google Analytics), with the overwhelming
majority being on mobile, I thought I'd better double-check how it looked in
mobile as opposed to just desktop to see if it could be improved. Turned out
it could - it was almost totally unusable because the image wasn't resized
appropriately etc. Not a single person pinged me about it.

It reminds me of something Neal Stephenson noted in "In The Beginning was the
Commandline": one of Debian's advantages was that it had a open public bug
database (still not universal! eg Apple), and you could very easily and
conveniently file a bug with 'reportbug' from your terminal.

~~~
rm_-rf_slash
Perhaps a solution could be to have a button that simply says “something is
broken,” and while it could open up a form for a user to submit a brief error
report, just the click alone could send fingerprint information about the
browser, so you could determine from the fingerprinting that most issues
happened on mobile, from China, etc.

That way if a user doesn’t end up submitting useful information, or it’s in an
unfamiliar language, or if they don’t even submit the form itself, you still
have data to work with.

~~~
DenisM
That's an _excellent_ idea! Call it "drive-by bug report"? Or "casual bug
report"?

I am now thinking how to combine the two channels - one is the regular support
channel where everything gets tracked and answered (we put a lot of work into
it), and one is for drive-by reports (so we just collect them and make
statistical inference but don't work hard on each incident). Most of my users
are logged in so I know who they are.

How about this:

1\. Is something broken on this page? [button]

2\. [button clicked] We've made a note of your report! We analyze all such
reports periodically. Would you like to expedite this particular issue?
[yes/no button]

3a. Form abandoned, no further UI action.

3b. [No] Ok, we will treat this as a low-priority issue. If you have any
details to share please put them here (optional field).

3c. [Yes] Ok, we will treat this as a high priority issue. Once you fill out
this form someone will get in touch with you asap. (What were you trying to
do) (What was the desire outcome) (Is it something that used to work but no
longer does) (...).

So 1-2-(3a|3b) is the casual path, and 1-2-3c is the firm path...

Suggestions?

~~~
lostlogin
From 2, ‘Would you like to add any comments or further information?’

Have a text field, a continue and an exit button. From the users perspective,
leave it there. A link to the bug tracker could be added.

~~~
DenisM
It's not just more information. The "Expedite" choice both requests more
details and puts the user directly into support queue.

------
gpm
One of the smartest things I think the rust project has done, is made it so
that when the compiler hits an unexpected error it tells you unambiguously
that it's a bug, and asks you to report it. It avoids any question of "well
maybe I screwed up, and the compiler did the right thing by crashing". Sure,
you might have screwed up, but so did the compiler even if just by printing
the wrong message.

    
    
        note: the compiler unexpectedly panicked. this is a bug.
        
        note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

~~~
tick_tock_tick
Honestly this is an example of exactly what the OP is saying is bad behavior.
The link to actually create a bug report doesn't even show up til the 5th
paragraph and clicking on that link just takes you to a github sign-in page.

~~~
kps
And the link to …/CONTRIBUTING.md#bug-reports doesn't actually _work_ ,
because the relevant heading has id=user-content-bug-reports" rather than
id="bug-reports".

~~~
gpm
Are you sure about that? I just tested to be sure, and it works for me (with
firefox).

I agree that the id in the html is "user-content-bug-reports", but for some
reason the link works anyways. Further if you hover over the heading github
displays a link icon to its left, and it points at #bug-reports.

~~~
kps
Hmm, you're right; there's an href="#bug-reports" that is somehow ineffective
on my other machine.

------
qdot76367
I actually had to plan this problem into my project. I run
[https://buttplug.io](https://buttplug.io), an open source library for
controlling sex toys. Due to the context of usage for the library, a lot of
our users will never want anyone to know they’re using our software, much less
reporting bugs on it.

This means I have to test early and often, and rely on people who are open
enough to even discuss usage in the first place in order to get bug reports.
This is on top of the fact that we support over 100 pieces of hardware, of
which I have maybe a third. It’s a odd position to be in.

~~~
adtac
using a .io for this is genius lol

------
vortico
For small projects, sure. The probability that a bug will be reported is

    
    
        number of users * prominence of bug * the "reportability easiness" reported in your article
    

I have an open-source project with 100k active users, and I mostly handle
issues myself, so I require the whole 9 yards of signing up for a GitHub
account (reduces the number of lazy issues) and filling out ~10 questions in
an issue template for both bug reports and feature requests. It works very
well for increasing the average quality of bug reports and filtering
duplicate, nonsensical, emotional, and information-lacking bug reports.

If you're on the other side of the spectrum and are just begging for people to
report bugs, then you should make it as simple as possible by allowing bug
reports from all mediums (GitHub, email, forum, Twitter, phone call, whatever)
and engage in the repetitive conversation it requires ("Can you send a
screenshot?", "What does the error message say?", "Can you send your log.txt
file?", etc.) But once the number of bug reports is more than you want to
handle for the project's salary, you should implement methods to send users
through a standard pipeline to avoid asking these questions every time.

~~~
dillonmckay
Can you provide an example of your issue template?

~~~
vortico
[https://raw.githubusercontent.com/VCVRack/Rack/v1/.github/IS...](https://raw.githubusercontent.com/VCVRack/Rack/v1/.github/ISSUE_TEMPLATE/bug_report.md)

~~~
detaro
A sentence suggesting a way to upload the file (maybe creating a Github gist
with it?) could streamline this a bit for the submitter maybe.

~~~
vortico
Perhaps, but in the GitHub issue form, it says "Attach files by dragging &
dropping, selecting or pasting them." so I'd just be mirroring the UI text.

~~~
detaro
TIL, I thought that only worked for images. nevermind...

------
mumblemumble
There's some expansion that can be done on that third option. Even if I'm not
very invested in a project, I'd be happy to mention a bug if it were easy to
do. But my experience has been that, if I report the bug, I'm going to start
getting asked for details about my system, and asked to try a bunch of things
to try and sort out the reproduction steps, and possibly even have maintainers
getting frustrated with me if I don't want to fix the problem myself.

Consequently, my unofficial policy is that, for an open source project, I'm
generally not going to bother to report a bug unless I'm also planning to fix
it myself.

The author is right, though, being super up-front about welcoming issues might
help break the ice a little.

~~~
account42
> There's some expansion that can be done on that third option. Even if I'm
> not very invested in a project, I'd be happy to mention a bug if it were
> easy to do. But my experience has been that, if I report the bug, I'm going
> to start getting asked for details about my system, and asked to try a bunch
> of things to try and sort out the reproduction steps, and possibly even have
> maintainers getting frustrated with me if I don't want to fix the problem
> myself.

A quality bug report should include system details and detailed reproduction
steps. Expecting "something didn't work for me" to leat to a fix is
unreasonable, especially when you expect unpaid vonlunteers to do the work.

~~~
mumblemumble
And there, I think, is the rub. So many open source projects see bug reports
as something of a zero sum game, where simply mentioning that something isn't
working quite right is seen as being a sponge.

I think that's a sad culture, but I go along with it. Hence the policy of not
even bothering to report bugs I'm not prepared to fix. The reason that's sad
is that it creates a culture where, as the author of TFA describes, critical
bugs that severely hinder the project's popularity by rendering it unusable to
many users might go undetected by the project's maintainer(s) for a very long
time. Because it creates a situation where potentially _every single person_
who encounters the bug will decide that the path of least resistance is to
quietly go find something else to do without bothering to mention that there's
a problem.

It's almost like a sort of cultural prisoner's dilemma. If we're all
charitable and try to give each other the benefit of the doubt, we'd probably
collectively be a lot happier and more productive. But the presence of a
significant subset of people who take a more stand-offish attitude means that
everyone's optimal strategy is to be a little bit stand-offish, for better or
for worse.

------
macintux
I have an odd hobby: I keep a close eye out for people with busted
brake/running/reverse lights so I can alert them.

One day I waited for a couple of minutes in a parking lot so I could tell
someone his brake light looked like it was out.

He turned to his co-worker who had followed him into the lot to confirm. His
friend told him it had been out for months and he just assumed he knew.

I don’t know what the takeaway is, but that mindset baffles me.

~~~
umvi
Why can't cars tell their their own lights are burned out? Seems like a simple
check of "is the circuit open or closed right now"?

~~~
macintux
Some do. No idea why it’s such a widespread problem other than “the government
hasn’t forced me to implement this yet.”

------
dalyons
This is why client & server side telemetry is so valuable.

People on this forum like to get all up in arms about it, but having it makes
for a much higher quality end user experience, as you can see all the problems
people run into. Not just errors, but bad ux flows, That cause people to bail
etc. It’s really been invaluable for all the products I’ve worked on in the
last 10 years.

Because yeah, most people won’t tell you.

~~~
nitrogen
Companies used to do this with focus groups and beta testers. Now they
outsource the work to their customers, at a high privacy cost.

If client-side telemetry is benign, then it should be fully removable for
people who don't want it (Firefox good, Windows 10 bad, web session replay
terrible).

~~~
octorian
> Companies used to do this with focus groups and beta testers.

Even with beta testing, you still run into serious bugs that are completely
unknown until the code hits production. There's far more diversity in the
runtime environment among non-enthusiast regular users than you'll ever
encounter in dedicated test efforts.

------
jeremyjh
Its not just open source; a lot of people won't tell you about bugs in
commercial projects or internal systems either. You need really good
telemetry/monitoring infrastructure and proactively find the bugs yourself.
But it isn't really practical to apply that strategy in open source projects.

~~~
bluedino
Out of all the remote offices, 90% of the calls and complaints came from one
guy, we'll call him Larry. Larry was one of those users who knew 'just enough
to be dangerous', he was a power user who often bragged about going to
'computer school'.

All of the help desk techs thought of him as a big thorn in their side, to
them it seemed like he called about all the most insignificant issues, and it
was almost like he intentionally tried to break things.

This crept over to the developers and management, who would ridicule the guy.
But what they didn't know was that he was probably their best tester! All of
the other remote offices didn't care that things didn't work right, and
assumed the bugs were already known and were never going to be fixed.

I truly felt bad for the guy, he was just trying to get his job done, but
ended up being the victim of both bad software, and bad technical support.

~~~
ycombonator
Every company has a over enthusiastic “Larry” who went to computer school.

~~~
1996
I wish I had had one at last company.

------
toxicFork
Thank you for linking this article.

> Nobody wants to look stupid or get told to RTFM, and so, they choose
> silence.

That's a great insight.

I wonder how many users are lost to "setup / entry point problems" in
projects.

These problems may not even be "bugs" but issues such as difficulties in
configuration, too many steps, something not entirely straight forward.

One thing that comes to mind is analytics to see conversion funnels, that may
work for websites but not so much for tools or libraries.

It's a great motivation for testing, and perhaps user studies. I would be
willing to pay a few bucks for someone to try my project and tell me what
issues they ran into. Unfiltered.

~~~
pjc50
Analytics inside libraries is the sort of thing that if HN finds out about it
you will get death threats.

Even if you want to help not everyone wants you looking over their shoulder.

~~~
sneak
They’re fine, just as long as they are opt-in.

~~~
acdha
That’s your opinion but it’s not universally shared and the people who take
more extreme positions also, in my experience, tend to be the most vocal about
any perceived abuse. All you need are one or two of them to spoil you on open
source for awhile.

~~~
sneak
It is not an extreme position to think that software spying on its users
without their consent is rude and inappropriate.

It's fine to collect telemetry, just as long as the user agrees to permit it.
Otherwise, your software is malware: it benefits you, at the expense of the
user's privacy.

~~~
acdha
The problem is how you define those terms: “spying” has a strong value
judgement and opinions vary widely, as does the threshold for what people
believe constitutes informed consent.

~~~
unionpivo
that's a feature not a bug.

If you go down and try pin those terms, you will get "language layers" that
will try to go as close to the line as possible and when they cross it argue
the definitions.

Be as open and forthcoming as possible.

~~~
acdha
I think you meant “language lawyer” or, given the context, just “lawyer” but
it’s not really what I was talking about: my point was just that projects can
define what they collect, what they do with it, and how to control it, and
they will still get angry rants from strangers on the internet. Analytics is a
really useful tool but it is also a lightning rod for criticism and conspiracy
theories.

------
ravedave5
This is soooo true. Launched a software product at my company, of course it
was supported 3 divisions over. Very few end users reported any bugs, which
then very few of those were passed along to our division, of which
management/business decided few of those were worth fixing. Once we added
proper telemetry it was shocking how many errors end users were seeing.

------
journalctl
Why would I report every random bug when it’ll just get closed in five years
as WONTFIX? Let’s be realistic: most FOSS projects are run by people who
already have a lot to do, and at least from what I’ve seen, the ability to get
any specific bug fixed is pretty low. So that’s why I don’t bother.

~~~
aasasd
Similar experience here, only with an addition from the other side: I'm
subscribed to some issues, and get seriously irritated by the number of people
who barge in with “This is a show-stopper for our company! We're not migrating
from ProductX until this is fixed! Surely it would take just a bit of time to
fix this!!!” Very often, such attitude is displayed on feature requests that
barely qualify above ‘cosmetic.’ Even on software for programmers like
Intellij Idea or Node.js, people whip out the ‘it's an easy job’ argument, or
post endless ‘me too’s while failing to comprehend differences in their use-
cases.

I see quite a few projects that get steady development, but have hundreds of
open issues, of which most are probably feature requests. In my experience,
having the tracker flooded with thoughts for features that it would be nice to
have someday, is completely useless and probably actively toxic. Ideas are
cheap, while implementers' time is finite. Ideas are best dumped into an
‘inbox’ list―most of them will never surface from there anyway.

As a result, I almost completely stopped posting issues, except for most
egregious bugs or when a feature would be a one-line change. As a rule, I now
prefer posting pull requests, which of course is a lot harder―but helps
keeping things in perspective.

------
cannam
Absolutely right I think. Getting feedback from users is surprisingly hard and
it's important to show gratitude for it even when it's bad.

I've found it quite hard to get feedback even when I push out beta releases of
an application specifically for gathering it. I think people feel that if it
isn't working, that's just "because it's a beta" and they'll wait and see what
the release is like before worrying about it.

------
jimktrains2
At work I actively reach out to people to ask how things are working, to the
point that I have a weekly scheduled check-in with each group to ask if
they've encountered anything wrong or that they feel is just too complex for
what the task is.

Once people are comfortable with both complaining and having things actually
get fixed, combined with I lucked out with department managers who are
competent and I can trust what they say and their assessments, this process
works extremely well.

It's really the small things that make the big differences. We added a
feature, but didn't add a link in the admin to the report for the customer, so
what should have been clicking a single link became a 10step process. Having
those lines of communication established, they messaged me and I got the link
added quickly. Sure, sometimes things get queued, but a lot of their asks are
small things that make their lives so much better.

~~~
natebosscher
That is such a great way of operating a software company! I wish more people
would get on board with this

------
rythie
I tend to assume anyone who reports a bug is likely about the 10th person to
experience the issue if it’s a big issue. Probably 100th or more if it’s a
more minor bug. You can sometimes see this for yourself if you have logs that
report 404/500 or other error and compare it to the bug reports you get - of
course often with open source you don’t have that info.

As a user it’s more effort than it’s worth to report bugs and when you do
people argue that it’s not a bug or take a year to fix it, which is then only
in some dev version you won’t see for years. This includes stuff I pay for
like Spotify.

------
noneeeed
Assuming that users, customers, or employers will proactively tell you when
there is a problem is the source of a lot of poor quality products, services
and work environments.

Many times that I've stayed in hotels there has been some small thing wrong,
like a blown lightbulb, or the toilet flush doesn't work well. I almost always
forget to mention it because its a small thing, but it impacts my opinion of
the hotel. These things fester until they become more serious.

I've used software and services with bugs and not reported them because I
assumed the _surely_ they must know of this glaring error, but apparently
nope, the didnt.

And I've known work environments where people just left rather than try and
improve things or air their grievances (including me). Previous attempts were
met with, at best dysfunction/ineffectualness, and at worst hostility, to the
point that people stop bothering.

------
gfodor
The author discovered this once he started a chat room. That is also a lesson:
create an easy, low stakes way to let people connect with you (a slack or
discord being a great example in 2019) and you’ll be more likely to get these
reports. Partially because they will be less effort for people to write a full
big report (mod joining the server) but more importantly people may feel
they’re more likely to get immediate help if such a channel exists. (Which may
be a burden for larger projects, but in exchange for that burden you’ll get
goodwill and the reports themselves.)

~~~
octorian
Monitoring user conversations about your product is absolutely critical, IMHO.
Even if you don't directly interact with them, just seeing their chatter can
be invaluable. Often times you, as the developer, will spot clues among their
rambling that point to actual fixable issues. Meanwhile, these same clues will
get completely filtered out and ignored if there's any sort of "user support
layer" acting as an intermediary.

Sure, there's a lot of chaff to filter through. As such, its okay if you don't
want to be the one interacting directly with the users 99% of the time. But
simply paying regular attention to what they're saying is worthwhile.

------
pmorici
"I’d never tested it on MacOS myself, but I couldn’t see any reason why it
wouldn’t work. I told this person that the problem was surely on their end."

Her reaction to the report says all you need to know about why people don’t
report things.

~~~
the_why_of_y
It's a self-reinforcing feedback loop of communication failure: users don't
report even the most obvious problem; maintainer assumes that if such a
problem were a general issue for all users it would have been reported by any
of the previous 100 users - but it hasn't been so the one user that actually
takes the time to report it must be holding it wrong.

------
igouy
I tried to build Ruby 2.7.0-preview2 from a source download 10 days ago.

[https://www.ruby-
lang.org/en/news/2019/10/22/ruby-2-7-0-prev...](https://www.ruby-
lang.org/en/news/2019/10/22/ruby-2-7-0-preview2-released/)

Build failed.

Spent 5 or 10 minutes trying to figure out how to report the problem, and then
gave up.

~~~
mnutt
Googling “ruby report a bug” gives me a How To Report Bugs in Ruby page, given
that it’s a preview release wouldn’t it make sense to use those instructions
to report? Or the instructions didn’t work?

~~~
sillysaurusx
It’s usually a hassle. You have to be very clear about what you were doing,
what your environment is, what the expected result was, what actually
happened, and how to reproduce it. And even your comment doesn’t link directly
to the page, so googling is yet another step.

Steps add up. I just think the process shouldn’t be so expensive. Goodwill is
nice, but people aren’t getting paid for it. (If only someone could figure out
how to convert bug reports into money. It’s possible; bug bounties tend to be
limited to security, but they’re successful in general.)

------
adrianmonk
Two other possible reasons, both having to do with how users view software
developers:

(1) They are naive enough to believe programmers have a better understanding
of their code than they really do. It never even occurred to them that it
would be possible that you don't know. Surely people who make software know
what's going on with it! How complicated can it get where you wouldn't know
that? (But we programmers know otherwise.)

(2) At the opposite end of the spectrum, they are cynical enough to believe
that you could fix it but just don't want to.

Basically, there is a story they have written in their mind (as is human
nature) about why it's not fixed, and the correct answer about why is
ignorance, but they may have assumed another reason.

------
yoz-y
Depends on the platform and type of bug I guess. When there is a bug in the
app I am publishing (and I don’t have many users) I do get loads of reports.

In this particular case it seems like there was no mention of macOS in the
project by default. In this case I would assume that people thought it was not
supported rather than a bug. Especially for low level projects it’s safe to
assume that it working on Linux does not necessarily translate to macOS

------
emrehan
> They assume that someone else has already reported the problem, and there
> would be no point in saying anything. The bigger your project, the more
> likely people are to assume that someone else has already reported the
> issue.

This is similar to "the bystander apathy" where bystanders are less likely to
help victims the more people are present around.

~~~
sverhagen
So, when I find a problem on a large project without finding corresponding bug
tickets, while I may then submit one, I may as well retreat, wondering if I'm
using the thing in entirely the wrong way, and rethinking my approach.

------
rgbrenner
This applies to your startup too... If your product doesn't work (either
entirely or in certain edge cases), most people won't tell you about it..
they'll just move on to something else.

That's why it's important to develop a closer relationship with your first
customers (and ideally, they're also depending on you to solve an important
problem). Otherwise there's little incentive for people to go out of their way
to fix an issue with a product they never got far enough along to adopt.

------
ninth_ant
> It’s a horrifying thought, but it could be that for every one person who
> opens an issue on GitHub, 100 or more people have already tried your
> project, run into that same bug, and simply moved on.

It could be 100, or just 1. And sometimes it’s hard to know which without a
lot of effort.

~~~
JJMcJ
This is very typical of all problems, not just software issues.

~~~
mwfunk
Yep. And if it’s truly an unknown, you have to assume the worst, it does no
one any good to assume the best.

~~~
JJMcJ
One reason companies do things on "the basis of only three complaints".

If three people complain, there might be hundreds or thousands who didn't
bother.

------
michaelbuckbee
Flipping this around: As a user what message would motivate you to respond?

I'm asking because I'm currently have the following happening in my SAAS:

1\. People sign up (paid,CC)

2\. People start onboarding (~5 steps)

3\. People drop out due to confusion/bugs/something

This is a developer-oriented service and I've tried emailing personally as the
founder reaching out for feedback. I've tried automated emails from developer
support.

Would live chat help? Offering t-shirt/amazon gift card for feedback?
Something else?

~~~
therealcamino
Do you email them asking for their feedback, or saying that you want to do
anything you need to to make them successful with your product?

~~~
michaelbuckbee
This is still small enough scale that I'm sending a personally written email
to them at signup asking for feedback or issues.

------
ken
The reason I don't file many bugs any more: in most cases, maintainers will
either ignore them, or come up with some excuse for not fixing it. Yes, even
for crashes.

Lots of projects (both open-source and proprietary) have a particularly nasty
habit of killing the entire project and starting fresh with something else. So
my bug might not even be relevant by the time they get around to it. Or they
might wipe the bug database, and I'll need to file it all over again. JWZ
calls this the "CADT Model".

I don't want to waste my time on the off chance that this particular
maintainer is a better than the rest.

This is why open-source _maintainable_ software is so valuable to me. If it's
something I can fix, I'll fix it, and send the patch upstream so you can use
it, too. If I can't fix it myself, I'll move on and find some other tool,
because I don't want to be stuck with some software that's too complex for me
to touch on day one. It's guaranteed to be too complex for me to touch on day
157 when I need a complex issue resolved for a production system right away.

------
euske
Somewhat related, but am I only one who're annoyed by the "Did you find this
information helpful?" form at the end of some help page? I'd usually just
click Yes/No, but then some sites forced me to type in the reason. At this
point, I'm like "screw this, I'm out" and just close the tab. Wonder how many
times this happened to others.

------
tpmx
Apple TV+ (tv.apple.com), just launched with a billion dollar launch campaign
is pretty broken in the most popular browser/os combo on earth:
chrome/windows. (It's also equally crappy on firefox/windows.)

(And there are some really weird design decisions in the Apple TV app. I think
they're fundamentally stupid and/or bugs, but the designers probably
disagree.)

It seems like they fixed some of the bugs since yesterday.. but.. they had
like two years to build this thing. Not impressed. There are plenty bugs left
that are trivial to trigger. (Random example: press space while playing to
pause, then press play to continue. Observe the glitchy weirdo animations.)

Now that I think of it, I assumed someone else would report the individual 3-4
P1 bugs I've found. (or well, that they would test this themselves...)

I think I held off because I figured that if they didn't catch these obvious
bugs, they didn't care. But now I read that Chrome is actually a supported
browser for Apple TV+, so.. I dunno what they doing during those two years.

~~~
octorian
This is why I always worry when some company thinks its okay to launch a v1.0
product directly to a massive userbase, starting from entirely internal
testing. There are so many cases you simply cannot or will not adequately test
internally, that its a disaster waiting to happen.

Internal users have a known system configuration, and a predictable set of
usage patterns, that will not be duplicated by the real world.

~~~
tpmx
You'd think they'd at least bother to test with the most common browser/os
combo...

~~~
octorian
Its possible they did, but were so locked into a prescribed way of using the
product that they never ran into the sort of bug an "untrained" user would hit
in the first 2 minutes of product use.

(Of course its also possible they didn't, or falsely assumed it would work
exactly the same as Chrome/OSX.)

------
pmarreck
This is basically the Bystander Effect as applied to software:

[https://en.wikipedia.org/wiki/Bystander_effect](https://en.wikipedia.org/wiki/Bystander_effect)

If this effect is in fact, in effect, here, then the number of visible stars
on your project might only amplify it, ironically!

Source: I was a happy Psych major who is happily doing dev now

------
thrownaway954
This is why in every site I build I have it email me whenever an error
happens. Unfortunately this is only for the backend code and I really need to
do this for the frontend javascript as well.

~~~
xsmasher
At volume, Sentry is a better tool for this than email; Sentry makes charts
than can help you visualize when a big started happening, lets you filter by
code version, user, OS, etc. and groups bugs my error message and/or stack
trace.

~~~
thrownaway954
dude... thank you for that suggestion. Briefly checked out their site and the
welcome video looks very interesting. this is something I definitely have to
consider adding to my stack:

[https://sentry.io/welcome/](https://sentry.io/welcome/)

------
cellular
The other thing that happens is that I'm reluctant to research if someone had
already submitted a bug, and so I won't risk submitting a known bug, because
the dev gets mad.

------
z3t4
Gotta love one-star reviews like "it doesnt work". I actually have a solution
to this problem. But it probably do not suit all businesses. When signing up
have a checkbox that say "I will report all bugs". Then have an easy way to
report them, where other users can help with workarounds. Then follow up and
answer _all_ bug reports. I think managing bug reports is a social problem.
You need to have empathy more then technical skills.

------
at_a_remove
My username is a little handy here. Often I would put together sites,
applications, etc., that would be used by people who were at least at one
remove. I would ask my stakeholders, "Have you heard anything?" Occasionally I
would hear that "well, this one guy said he didn't like it about six months
back." That's it. I tried to have people look at what was going out before
release but nobody could seem to find time to do so.

I had even posted my direct phone line on some of these sites, as well as a
troubleshooting walk-through in the form of a clickable flowchart and a form
that would be sent right to my inbox, yet I got only crickets. Faced with this
kind of behavior, I would literally face users in their dens to ask them. If I
saw a student using it when I was out and about, I would say, "Hey, I'm the
guy who put that together. Please tell me about your experiences, good or
bad." Oftentimes, despite my requests to meet with other users (I even offered
to drive to people's offices to help), I would be told that the stakeholders
would "collect feedback." Often my chain would be yanked for my attempts. No
feedback was collected, or if it was, I never heard about it.

This was not just me. We might find out that a printer had been having a
problem, and then be told, "Yeah, it's been doing that for a few months now."

I am not sure entirely what was going on, but it wasn't for lack of effort on
my part that I did not find out. To some degree, I believe there is a culture
among users, management, and stakeholders that programmers can be blamed for
only by trying very hard to do so.

------
l0b0
Most of the time other people _have_ already reported egregious bugs. Spending
hours investigating a bug and reporting it, especially to a big project, is
much more often than not wasted time:

\- Search for a duplicate for 20 minutes and find nothing. Spend another five
minutes on a search engine because the ticketing system search results seem to
have nothing to do with your search terms.

\- Spend five minutes signing up for the N+1th bug tracker.

\- Two or more hours gathering details because every single bug tracker wants
all the details upfront rather than just a problem description. Understandable
but frustrating because of what comes later.

\- Adapt the findings to the N+1th bug template in the N+1th inferior Markdown
imitation.

\- Submit.

\- Wait for an unknown length of time, sometimes years, without a _human_
response.

\- Once you get an answer is when it gets _really_ frustrating, because most
of the time it is _not_ a new bug. Issue tracker search is just not anywhere
near smart enough to save the community millions of hours every year filing
duplicates. I must've filed two duplicate bugs for every non-duplicate, and
believe me, I really try to save those hours by searching first.

------
bcrosby95
I've worked on websites where people paid a monthly fee, and when certain
things didn't work right people never told us over email or phone. Only when
we met in person at a convention did they tell us.

The users having the problems were Chinese though, so I'm not sure if it's a
cultural thing. Our regular US users did seem more willing to tell us about
broken stuff.

------
tempestn
I think a big reason people don't report bugs is they've come to expect that
nothing will come of it. For instance, there are major bugs with Quickbooks'
multi-currency support that I have reported repeatedly over the course of
years, with detailed steps to reproduce, and received not so much as a reply
let alone a fix. On the other side, any time someone reports a bug on one of
our websites, they seem positively shocked when we answer and usually are able
to fix it that same day. (We have also found, as with the OP, that bugs can
affect a lot of users before one will send a message, so we definitely do try
to catch as much with testing and code review as possible!)

------
Ididntdothis
I do mostly in-house stuff but I always get nervous when we roll out something
and don’t hear anything back. Either it works perfectly (which it rarely does)
or it doesn’t work and people have given up. Usually it’s the latter.

------
coryvirokmobile
I can't tell you how many times I've heard this from customers. There have
been so many times when a customer thought a bug was their fault or expected
behavior. That's even more surprising because our customers are developers
themselves.

Automated error monitoring is becoming more and more important, especially
when you don't have the time or resources to add proper integration or
platform testing to the project.

This is one of the reasons we built [https://rollbar.com](https://rollbar.com)

Fyi - I'm one of the Founders

------
retonom
and then consider the typical project on Github which makes it intentionally
hard to open up an issue, like with a template where you need answer 10
questions right down to your underpants size...

~~~
reificator
It's a tough balance. You start a one-dev project for free that gets big,
suddenly it's next to impossible to keep up with support requests.

If your project is targeted at developers, you might be able to find someone
you can trust to help you out, but if it's targeted at non-technical users
that's like finding a unicorn.

I'm not arguing in favor of keeping people out of course, just that it's not
as straightforward as "issue templates bad" vs "RTFM noob".

~~~
toxicFork
It sounds a bit like the opposite side of the customer acquisition cost versus
lifetime value.

Traditionally if you have a high user lifetime value you can spend more money
on getting more customers by increasing your marketing spend so your CAC
(customer acquisition cost)/LTV (lifetime value) stays at a good level. So you
can keep a good growth curve.

In this case when your ltv is negative for each issue because of low quality,
or simply too many of them then you make it harder for new issues to come in,
which should ideally result in fewer but higher quality reports?

I have a question mark in there because I did not spend a lot of time
considering this, but I like the thought.

------
leeoniya
there's a difference between showstopper DOA-type bugs that cause a project to
simply not work _at all_ and bugs that prevent the product from working to its
full capacity (intermittent crashes, perf issues, lack of or sub-optimal
features/ui).

the author is writing about the former but in my experience (both as a
maintainer and contributor) people are a lot more motivated to report and work
on the latter type rather than spend hours just to get off the ground...and it
makes sense.

------
suzzer99
Do you think google is not aware of how terrible Chrome's auto-correct
suggester is? Mind blown.

IE - it has no idea what words I'm trying to type: civillian, millenial,
EMBARRESSED. (for some reason the last one works fine in lower case, but can't
guess in upper case - even though it guesses some words in upper case)

It seems to struggle with double vs. single letters. I've always just assumed
they don't care. But maybe they don't even know.

------
jarofgreen
Applies to many things. I once went to a Hackathon where shortly after it was
over the organiser tweeted about having "nailed it" .... At the exact time a
bunch of attendees were at the pub round the corner complaining about it. As
far as I know, none of us told them about our issues - but also, they didn't
do anything to encourage us to provide feedback.

------
xhruso00
Reporting bugs is considered as work for most. I gave up on Apple cause I am
not paid to report.I only report those which affect my apps.

------
Ice_cream_suit
"I explained that I’d never tested it on MacOS... , but I couldn’t see any
reason why it wouldn’t work"

Right...

~~~
Ono-Sendai
Indeed, if you haven't tested your code on a completely different OS, you have
to assume it doesn't work.

~~~
loriverkutya
He explained later, that contributors used it on Mac and it was working for
them.

------
platz
I truly wonder how many people this affected but didn't think to open an issue
on GitHub
[https://github.com/mjackson/unpkg/issues/229](https://github.com/mjackson/unpkg/issues/229)

------
hinkley
Or, by the time they tell you it’s broken, they’re so agitated that it’s
difficult to get good info out of them.

Sometimes instead of giving up, people just get more upset.

------
bredren
People so rarely Take the time to report issues, I go by a 10x rule. If I hear
about it, at least 10 other people are experiencing that issue.

------
fierarul
This might explain the Windows Home unstoppable telemetry. With all this
information Windows better become flawless.

------
diminoten
> The more important lesson, that I didn’t understand until that point, is
> that you can’t count on the people trying your project to quickly and
> reliably signal bugs to you.

Took awhile to get to this line, and I feel like it was the thesis.

