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.
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...
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"
- 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.
At least you maintained separate email addresses so compromises are sort of firewalled.
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 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.
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.
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?
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).