They Might Never Tell You It’s Broken
pointersgonewild.com
pointersgonewild.com
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.
-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.
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.
Imagine a site that has elements from the above mentioned and also StackExchange or even the Apple Discussion boards. The input would be people reporting bugs they encounter: is it reproducible? known workarounds? maybe severity ratings. A "page views" count.
The output would then be either selling or giving away aggregate reports to vendors, like Apple. "Hey Apple, here are the most important bugs people are reporting. We suggest you fix these first."
If anyone has interest discussing this further, get in touch.
iPad, never. Randomly, after 10-30 minutes, popup appears. A dozen Apple support pages tell me to move closer to the router that my iphone connects to. Each page has eleventy-billion “I have this problem too” with no other mitigation.
I’m convinced no Apple employees use hotels. Probably airbnb it or dont travel.
I'm surprised Safari does this...
One example from Cisco: https://community.cisco.com/t5/wireless-mobility-documents/w...
Pretty much no bug I've ever reported to Apple has been looked at, let alone any kind of fix.
So, I stopped reporting anything long before leaving the Apple ecosystem.
I tried bugreporter.apple.com and you need to log in as a developer. Has that always been true?
And it goes the right way for a while after a huge embarrassing bug that causes a problem with a major client and the bosses have to scold everyone, and then slowly stops again.
Then they become susceptible to internal fake news,e.g "I heard someone in Dev say they'd never fix that, it's too hard to test". Or "Dev seem to have a policy of only working on new features".
As well, support knows that many bugs go unfixed for years/months, and/or the issues that do get fixed don't seem to make sense (to them anyway).
So eventually they stop reporting or pushing for bugs.
The next stage after that is that this world view gets propagated outside the company - support (maybe subconsciously) lets customers know that there's really not much chance of this issue being fixed.
Then customers get the vibe that the product is not being maintained/ the company's priorities lie elsewhere.
In turn the customers talk about themselves and perhaps move that little bit more towards going elsewhere.
IMO it's a very dangerous situation and companies should take extremely strong measures to keep a positive mindset in the support team, whatever that takes.
But, I think customer support people are also trained (somewhat rightly) to shield the rest of the organization from complaints. They view it as part of their job to be the ones who handle stuff so other people can concentrate on other things. Sometimes they just get confused and take that too far.
If you're in support, sometimes the people who maintain the product need you to run interference for them. Sometimes they need you to hold them accountable. The line can be a little non-obvious at times.
Working hard to remove duplicates is great, but frequent reports have to be signaled as urgent to the devs.
Then there is the tendency to only forward stuff that is somewhat reproducible, especially for unique reports. This makes entire classes harder to get through.
Sure I could find more... so yeah, many structural aspects of the job are set us up to break the link between customers and devs unless everyone is mindful.
They'd then compile a weekly-ish report of (1) top 10 most common issues they were seeing, and (2) issues that were new this week or went up a lot from previous weeks.
That information as pretty easily digestible for the development team, and it helped us understand the size of the impact of known issues. And ones we didn't recognize, we could request more information on.
The support manager also made a point that if a new issue came up and seemed to be particularly prevalent or major, they would proactively contact dev instead of waiting for someone to read a weekly report.
I've even sent a few bug reports, and one of them got a request for more info.
None have been fixed though.
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).
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?
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.
https://www.apple.com/feedback
for example:
https://www.apple.com/feedback/macbook.html
It is stupid though. It says:
> If you provide your email address, you agree that we may contact you to better understand the comments you submitted.
which makes it seem like it is optional, but then below, the email address field is marked "required"
At least you maintained separate email addresses so compromises are sort of firewalled.
I agree though sometimes I dont bother reporting bugs if its not on GitHub or a system I am already registered for.
It’s exceedingly common for open source maintainers to reply on bug threads with disingenuous reasons and mental gymnastics to avoid calling a bug a bug, and try to pass it off as an obscurely defined feature request or grumble that whatever use case is hitting the bug “shouldn’t” be supported or would require structural changes to the design (which is what caused the bug) that make it the user’s fault for wanting something that would require scrambling someone else’s arbitrary design choices.
A big example from my recent memory is bugs with various cloud storage APIs that result from blob storage not behaving like a real file system, but user semantics still relying on path delimiters that group things into a hierarchy of directories.
People get disinfranchised because you’ll be given some parochial, nonsense dismissal saying that the backend being undifferentiated blobs somehow means the user shouldn’t rely on filesystem-like abstractions, instead of the library maintainers just doing the work and adding indexing and making the API functions automatically deal with delimiters & key prefixes so that it “just works” like a set of folders to the user (who doesn’t and shouldn’t care about an unrelated implementation detail like blob storage).
This is just an example, but illustrates a wider point. You often feel like what’s the point of reporting this bug? I’ll just be given some empty dismissive answer about how it won’t get solved and I should philosophically refactor my entire use case from first principles so as to not need what I need.
Click on the bug icon. It takes a screenshot. You can then choose not to send the screenshot and add information about the problem before you send the report.
I still haven't been able to get the CloudFlare VPN to work, but they're at least super nice and very responsive to bug reports.
Safari used to have a bug icon. It really should have one again.
My biggest problem with a mailing list is -- I have no idea how to use it but avoid spam.
But obviously they are still used, so there must be some way? How do others solve that problem?
80% of 'creators' on the internet have never heard of GitHub [0,1]. If we use 1 repo per person, we get about 1M people using git. Assume the 1-9-90 ratio, and you get about 100M people that have heard of git or clicked on something like it even once. About 5B people use the internet today. Say the same 1-9-90 ratio applies to users of the internet. You get ~500M 'creators' on the internet. Assume all of the people that have used git are 'creators' on the internet. 100M out of 500M is ~20% of the 'creators'. Meaning that if a random 'creator' is selected, there is a 1/5 chance they have used git in addition to using whatever thing they are currently using. This is a quick and dirty run-down neglecting a lot of stuff (english language, age ranges, sex differences, firewalls, etc) and smoothing over a lot of stuff too (1 repo/person, age ranges, 1-9-90 ratio, etc). But I hope it demonstrates that it is not anywhere close to safe to assume that anyone paying you for a product has any idea what GitHub is.
[0] https://www.openhub.net/repositories/compare.
[1] https://www.allianttechnology.com/how-many-people-use-the-in...
- Account-based authentication for numerous systems has reached a point of increasingly negative user returns. Experian (citing unspecified research, probably a 2015 Dashlane study) notes that the typical user had about 100 accounts -- 130 for the US, growing at 15% per year, or alternatively, doubling every 5 years.
https://blog.dashlane.com/infographic-online-overload-its-wo...
- Crud reports are crud. I've got an issue with an Android app I use heavily (Pocket), which has been crashing with exceptionally annoying frequency (30x/week by one Android report, which suggested uninstalling the app). I've taken to simply reporting those, for various reasons without the ability to report this as the Pocket user, simply noting "app has crashed again". Pocket have finally responded (after weeks). The problem itself has been ongoing for years.
- There should be an analogue to James C. Scott's Seeing Like a State for software / SaaS vendors. Call it "seeing like a software developer". The power of software is that a small group (and frequently a single individual) can create a tool that is useful for and used by many -- hundreds, thousands, millions, billions. The weakness is that gathering and assimilating useful feedback is extraordinarily difficult. Most feedback channels can be overwhelmed by a few high-volume (and often not-particularly-useful) actors. Quality information is difficult to acquire. Sorting useful from non-useful information is expensive.
https://yalebooks.yale.edu/book/9780300078152/seeing-state
- Grouping similar bug reports is a challenge.
- Numerous projects fail to prioritise interests of advanced users. Something I've termed "the tyranny of the minimum viable user". Given the vast range of user skill levels, and the overwhelming domination of low-skill users, this has profound implications for the future of software, computers, and systems.
Well of course there are people who don't; most of the users don't. Basically only a part of the dev community have Github accounts, that's far from representative of the userbase.
I do get bug reports via email that nobody had previously reported to Github. So it's definitely a win.
But bug reports via email are still rare.
I once shipped a version of my app that had a really serious issue (text editor crashed whenever you pressed backspace). From automatic crash reports, I know that hundreds of people were affected. My app was practically useless.
But I only got a handful of bug reports (I think it was less than 5 customers who complained). The vast majority of users just accepted that there is a bug and did not realise that they could email me and I would fix the issue within a few hours)
github requires an account.
email requires disclosure of an email address.
Any barrier to bug reporting is a footshoot of the highest order.
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.
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.
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?
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.
[1] https://www.washingtonpost.com/technology/2019/10/31/think-y...
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-reportscc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See <URL> for instructions.
(the URL may be customized by the distro)
The point of technical error messages, imo, is to tell the developer what they did wrong to get into this state. They can't be allowed to be wrong, otherwise developers stop trusting them (this bites us a lot - we get dozens of incidents along the line of "error says very specific thing related to my scenario is configured wrong - is it actually?")
> So, what can you do? You can encourage people to report bugs. I visibly write in my GitHub README that reporting bugs is encouraged and welcome: “Please tell me if something is wrong, you’re helping me make this project better.”
Nothing in the post is about frictionless report submission, mostly observation that if something is broken most users won't bother reporting it. If the suggestion has been made that bug reports are welcome, that might help, and a good place to make that suggestion is in an error message, especially for a development tool (though it is also in the main README).
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.
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.
number of users * prominence of bug * the "reportability easiness" reported in your article
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.
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.
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.
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.
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.
https://www.thisamericanlife.org/239/transcript
World needs more people like you. Keep up the good work!
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.
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).
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.
However, that god awful search in Windows 10 is the exact opposite of this ideal. It seems to get worse and more inconsistent in every iteration. I hate it in particular when a web search result gets displayed instead of my locally installed app that I spelled out and when I absentmindedly hit enter before reading the small print in the result, a new Edge windiw greets me. It's not even my default browser. How's that for bugs?
Going with a self-hosted solution instead of GA goes a long way to gain my acceptance.
The answer to this would simply be to test it on OS X. Or just state that OS X isn't supported - or just do nothing. All three are acceptable for a project like this.
Telemetry is not.
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.
At my moms job she was the leiasion for printer problems. You'd think she broke the printer a hundred times, but instead shes the only person that would call support when they happened.
But, and this is the important part: depending on how the company is structured, reporting a bug in a closed source project will result in unplanned work. If the company takes a "everyone is responsible for all bugs, we don't assign blame" then it is likely someone will report it.
If the company, whether explicitly or implicitly, is communicating that if you report the bug, you fix it, then there is a good chance you will not report it, if you own it.
If you own something, you can be fired if you break it. So there is a perverse incentive to not report your own bugs, especially if you inherit a mess.
In my bubble, you have to be very careful about hiring because it can be very difficult to fire anyone at a large company. Or it just ends up being such a long, awkward, multi-stage process, that even objectively terrible engineers will get transferred elsewhere within a large company rather than get fired, because it's that much easier for the manager who wants to get rid of them.
Some of it might be a cultural affinity for giving people second chances, but I think a lot of it is just the hoops you have to jump through to avoid the possibility of a future wrongful termination lawsuit if you fire somebody. But I've heard that it can be very different elsewhere, in different industries or countries. I bet it has a lot to do with the legal system too, like whether or not there's a framework of worker protection laws in place.
It probably wasn't the most popular product to begin with, but I am still amazed that nobody even noticed the drop in sales.
Yet the feedback has been almost non-existent. We just have to assume it all works as intended, but we know that's too good to be true. When we grab people they say "oh yeah, I was going to report a bug but now I can't remember" or we'll see that people just stop using it because of some game-breaking bug, which they never report. Some people even say "don't use it, it's broken" and just assume we magically know about the bugs.
The worst part is many of these projects are explicitly made to help test the API, and help improve it. Yet they don't report anything.
Worse still is putting your manuals behind a login. I know some companies believe they're valuable secrets for some reason, but most of your customers will simply never be able to log in to get them.
In these cases, you will never recoup your NRE.
Oracle has sued competitors for handing out copies of the manual, suggesting requiring a login isn't much of a barrier: https://www.bizjournals.com/sanjose/news/2013/06/18/oracle-w...
You have to learn to really watch people when they’re using your team’s code. It’s so much clearer than listening to them bitch about the three things that triggered them.
Sometimes, you have used your own code way too much to judge effectiveness.
Having a no-agenda meeting with users is also a great idea, but it is important to set scope on feature requests before it snowballs into a request for the moon.
> 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.
Even if you want to help not everyone wants you looking over their shoulder.
I guess that is why some companies have open beta versions where in the eula you agree if you use this version you will be analysed. See Microsoft Windows insiders edition, Jetbrains, etc.
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.
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.
If you have 100 million users, depending in the bias inherent in opt-in reporting is deadly. You need the statistical correlations for a lot of things to be tractable. You can't afford to staff your development organization as a percentage of your user base, not if you have any competition at all. You'll have to get comfortable with some things that feel like software malpractice at smaller scales - such as accepting that bad RAM really is a significant source of problems when you have millions of users, and you'd better get a feel for what the resulting problems look like.
It's different of course if it's a large well-known project, but there are enough smaller projects that really aren't ready that it often doesn't feel worth it to report things like that.
But, somehow both sides end up treating it as a work request, and that causes bad feelings.
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.
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.
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.
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.
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.
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.
Her reaction to the report says all you need to know about why people don’t report things.
I personally try my hardest not to declare that X works on/with Y until I've seen it with my own eyes. Not 2 computing environments are the same, and everything receives updates all the time.
https://www.ruby-lang.org/en/news/2019/10/22/ruby-2-7-0-prev...
Build failed.
Spent 5 or 10 minutes trying to figure out how to report the problem, and then gave up.
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.)
(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.
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
This is similar to "the bystander apathy" where bystanders are less likely to help victims the more people are present around.
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.
It could be 100, or just 1. And sometimes it’s hard to know which without a lot of effort.
If three people complain, there might be hundreds or thousands who didn't bother.
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?
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.
(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.
Internal users have a known system configuration, and a predictable set of usage patterns, that will not be duplicated by the real world.
(Of course its also possible they didn't, or falsely assumed it would work exactly the same as Chrome/OSX.)
They're probably not doing any more DRM than e.g. Netflix. Anyway, it's pointless - the launch shows are already available on The Pirate Bay. I'm sure the video/audio/subtitle quality is excellent.
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
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.
- 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.
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.
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
Fyi - I'm one of the Founders
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".
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.
You need to gather some good information, You need to explain it in terms that are understandable, and you probably ought to put a little effort into making sure you weren't creating a duplicate bug.
Not that that invalidates your point. It's enough work on its own without adding extra unnecessary work.
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.
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.
Right...
Sometimes instead of giving up, people just get more upset.
Took awhile to get to this line, and I feel like it was the thesis.