> 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).
I've found bugs with Xubuntu and started trying to report them, but I just gave up after 15 minutes since the process of reporting the bug was more of an inconvenience than the bug itself
Whenever I've found any kind of bug in Xubuntu or Ubuntu I would just rise a question about how to fix that on askubuntu.com. If it was my fault rather than a bug the folks would help me, if it was a bug they would confirm that. Some times I would even post a question and answer it myself immediately in cases when I've found a problem and a way to fix/workaround it myself. This way I make sure I'm not the only to know about the bug, the bug and the fact somebody is affected is known to the public. I just hope Canonical engineers actually read the site occasionally.
Weirdly enough someone reported a Ubuntu bug I had and I was able to just respond to the email chain with more useful information as to the cause and that was that. I think mailing lists are powerful they just need to be clearer on how to use them and have some tutorial links towards the bottom. Dont ask me how you start a new email chain for a new bug though. I wouldn't know. To be fair I dont remember how I responded initially.
I agree though sometimes I dont bother reporting bugs if its not on GitHub or a system I am already registered for.
Yet another reason people might not report bugs is there can be an attitude of hostility towards reporting bugs by open source maintainers whose priorities don’t align with helping their users.
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.
> 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).
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.
Jetbrains had absolutely fantastic support when I first started using their stuff 10+ years ago. it's kind of sad that the support has gone downhill since then, but on the other hand I don't run into problems as often either.
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.
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?
> 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.
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.
- 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.
- 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.
- 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.
At some point in time I felt the need to make an anonymous Github account. It's quite annoying to know that people can google your name and see what you did in the last few years.
Realistically that should be the default for everything on the internet.
Everything I do online is under a persona, I try to sign up for as little as possible under my own name, and email address. Subsequently the email addresses I use to sign up for most accounts have been pwned (on https://haveibeenpwned.com/), but my real email address is fine.
I've found that the CloudFlare VPN bug reporter is the most user-friendly.
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.
I accept bug reports both via email and via Github.
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)
> they probably have a GitHub account already (but I still believe there are people who don't)
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.
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).