I use to report bugs all the time with details of the bug and what I was doing and if possible how to cause it. But then when you encounter the same bugs years later doing some very common task that you momentarily forgot to do your work around for, it made me wonder why I was wasting my time reporting it. These days I rarely report bugs unless it is brand new software released a few weeks ago at most, or a brand new release of older software with a new bug. If something isn't completely breaking the use case of a program, or doesn't have any viable work around, I just don't expect it to ever get fixed. So why waste the time? Im not getting paid for it, it likely won't be fixed, and 49/50 bugs I encounter are things that seem impossible to miss with any real QC.
Doing decent bug reports as a user most of the time it feels like following the turnip truck to town picking up turnips that fell off the truck, giving them to the farmer, but knowing they will likely be thrown in the trash because they didn't care about them to start with. If they did they would have made sure to not overload the truck to start with and not be obviously dropping so many turnips on the side of the road and leaving them there.
It depends on the company. I’d never dream of reporting a bug to Apple, they don’t care. I think your turnip truck analogy applies there. On the other hand, iA Writer consistently replies thoughtfully and usually fixes the bug.
It’s so important to treat companies individually instead of just according to some blanket impression of the world. Individual treatment means good companies benefit and grow, while blanket treatment actually actively rewards bad behavior: a company that invests in quality will bear the cost while you share the benefit with the competition, while a company that treats you worse will reap the savings while you take out your frustration on the competition, too.
Then there are the ones who send you a detailed response trying to convince you that it isn't a bug, when it definitely is one. I've switched programs over that, not because the bug itself was that important, but because I don't like running code that I've established to be written by boneheads.
I submitted a feature request to Apple to allow silencing the ringer for anyone who isn’t in my Contacts list. A year later with the next major update, the “Silence Unknown Callers” feature came to iOS. It appears it worked, either that or it was just a wild coincidence. Of course many other feature requests I’ve submitted over the years still do not exist, such as a global toggle for explicit vs clean music (when it’s just me I always want the original version, but if there are kids in the car, I want an easy way to clean everything up).
I know someone else who has called Apple’s support line and spoken with engineers on bugs that were uncovered. He then got follow up emails to install the latest macOS update as it contained a fix to the bug he stumbled across.
Counter-anecdotally, I reported two WebAuthn issues to Apple in separate instances and both were immediately fixed in the next patch version of iOS/Mac OS. In both cases first line support had little understanding of the issue but were very good at following process, trusting me, calling me back to keep me updated, and escalating to engineering as necessary.
I've done the same with Windows, but I had a unique bug with Storage Spaces and did some debugging to identify driver issues to include with the report. I guess the reason it was fixed was because there was similar feedback without the debugging on the Windows Feedback app and because the blast radius was small. It was just one .sys file, but even then Storage Spaces is relatively contained.
Compare that to any GUI-related issue. Almost every surface has some kind of unsupported/unexpected hooking or reliance on unchanging elements because some company has built a tool that integrates. They've then sold this to Fortune 500s who explode if Windows blows up their tool. This makes the startup cost for fixing many things very expensive.
If you report issues related to higher profile/usage functionality then you are less likely to get traction because:
* They know about the issue already, but it's a really hard to fix for some reason which may not be obvious to you. All stakeholders are not equal in the decision process hence compatibility concerns win in some situations.
* Even if they decide to fix it, a huge amount of effort has to go into scheduling the fix in a release. Some authority may agree to go fix it and everyone is excited. That's just the start of a painful process to implement and test the fix.
> If something isn't completely breaking the use case of a program, or doesn't have any viable work around, I just don't expect it to ever get fixed
Yep. That has always been the general industry sentiment [1]:
> Here’s another bug that’s not worth fixing: if you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn’t even use large files. Well, don’t fix it. Worse things have happened at sea. Similarly I’ve generally given up caring about people with 16 color screens or people running off-the-shelf Windows 95 with no upgrades in 7 years. People like that don’t spend much money on packaged software products.
>But mostly, it’s worth fixing bugs. Even if they are “harmless” bugs, they may reduce the reputation of your company and your product, which, in the long run, will have a significant impact on your earnings. It’s hard to overcome the reputation of having a buggy product.
I wish that was the case. I suffered Crowdstrike being force installed upon all servers at a previous firm. After every system update it would "lose" it's configuration and proceed to try scanning every attached drive, some of which were in the petabytes. It's inefficient scanning process consumed 70% plus CPU and caused service outages for some users. Each time we'd ask for configuration to be added to ignore certain mount points, each time it would get turned on again. The only thing that saved us was distributing the service over multiple servers in different regions so that their updates were staggered. We spent >5% of team effort for a few years fighting Crowdstrike.
Just under a year ago they caused a global outage (https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...). I thought, aha finally they will pay for their sloppy software. Then I checked the share price today, it's up 20% in the last year. If a cyber security company can cause one of the largest global outages ever and go relatively unpunished, I'm not surprised some firms are not fixing bugs. Very disappointing.
I've reported bugs in a few projects. In my experience, the smaller the team behind the software, the more likely your bug will be fixed.
I think I've reported bugs to Bloomz (the awful communication app my school uses), jpmonette/feed (the node/typescript RSS feed generation library), and I think at one point I reported one to Newsblur, and they all got fixed.
I submitted a bug report on Things To Get Me (an Amazon wishlist alternative) on a holiday weekend, fully not expecting to hear anything until at least Monday. It wasn’t anything too major. Within the hour I not only had a response, but a change was pushed to prod after a little back and forth with the developer.
A couple years ago I signed up for write.as and the founder/ceo reached out to have video chat just to see how things were going or if there was anything I’d want to see in the future.
Yeah... unfortunately this is how it is at my company which is a startup, I reported so many bugs that just got ignored and it can be demotivating to see the same bugs still in our app months later that could've been fixed in 15 minutes
I've had the opposite experience reporting a bug on Telegram. But it was a particularly thorough report (windbg and all) and if that's what makes the difference, it seems like an unrealistic thing to expect of most users.
The problem with bug reporting is that they rarely seem to get fixed. I used to do a lot more bug reports. But you often hear back nothing, and then the bug is never fixed, even if it would be an easy fix. These days, I don't often report bugs.
Some teams have a frickin' bad attitude and couldn't care less. Try submitting a bug about how menus are displayed 5px from where they are supposed to be in a GTK app rendered on a X11-server that runs on the Windows desktop and see if the GTK developers care. Or try telling the react-testing-framework folks that they're asking me to put handrails in my bathroom when my house is burning down. Have experiences like that and you'll conclude it isn't worth filing bug reports.
Now the linux-industrial complex is a special case, if you are a software engineer and know how to isolate a problem and submit a great bug report you will often hear from people who will say you sent them the best bug report all quarter. It helps if the team is working with web tech, younger, more diverse, and never heard of the GPL.
Don't forget all major OSS repositories using a stale bot to close any issue regardless of how many people reported it or how serious it is. Close and lock at times. Yikes.
I have seen OpenZFS adopt one, but whenever I have seen a bug that has merit closed by the stale bot, it is reopened by a contributor and a not-stale flag is added to prevent it from being automatically closed again. Note that I am a contributor, but I am not one of the ones who is reopening bugs and marking them as not stale. The few times I saw such a bug and would have done it, someone else beat me to it.
The stale bot approach does help in cases where a bug does not have merit. For example, not that long ago, a user opened a bug asking us to rename the ZFS Event Daemon so a text editor could adopt the daemon’s name. The consensus among contributors on the discussion is that we will not do it, but no one has volunteered to be the one to close the bug. The stale bot will be closing that one for us.
I think that once a bug has been verified and keeps getting likes, it should not be closed.
If the user never responded to further questions, then absolutely.
What I see however is that maintainers themselves fight the bot removing the label and reopening issues. Over and over. Until they miss the notification.
> The stale bot approach does help in cases where a bug does not have merit. For example, not that long ago, a user opened a bug asking us to rename the ZFS Event Daemon so a text editor could adopt the daemon’s name. The consensus among contributors on the discussion is that we will not do it, but no one has volunteered to be the one to close the bug. The stale bot will be closing that one for us.
That doesn't sound like an even remotely ideal way to handle that. Don't just needlessly string the original reporter along until some arbitrary time limit expires.
It should be obvious to him that it is not happening given that several contributors all responded no. As for closing the bug, no one has volunteered to be the one to do it.
Yep, stale bot got me to stop reporting bugs to Kubernetes, I spend time to gather details for an useful and it just gets closed without any human interaction. That's super disrespectful.
I stopped reporting bugs when I see the repo is using stale bot. One thing is to be ignored for a while, because maintainers are busy. Another one is to be told "we ignored you long enough, it is not an issue".
Yes it still is. I made a reproducible example, try it out.
Yeah if I see a bot like that I just don't bother with bug reports to that project. Absolutely disrespectful to not even bother having a human look at the bug to decide if it can be closed.
GTK is developed entirely by volunteers. None of the "rules" of bug reporting in this thread apply. If it's a business selling something to you? Sure, don't bother if they don't seem to care.
But with volunteer-driven FOSS projects, what you want as an end user is much, much lower on the list of priorities compared to a business product. Even if you have implemented the "fix" [1] yourself, they might still not accept it unless you're willing to stay around and maintain it yourself. And that's perfectly fine.
[1] Assuming that the maintainers agree that it's a bug and not a feature request in disguise.
This doesn't change the original point that such behavior makes it less likely for users to bother with detailed bug reports. Bug reporting in OSS isn't just the developers doing free work for the users to fix their issues, it is also the users doing free work for the developer QA-testing their software.
The thing I dislike the most about the Linux world is how free software/developers are somehow exempt from any kind of criticism because it is "developed by volunteers."
I completely agree with you. It's generally bad form to complain about something that is provided to you free of charge but sometimes even then criticism can be warranted. There is a tendency to immediately swat away any kind of criticism of a project or even just a particular developer's behavior with "how dare you complain about free software!!!".
> Try submitting a bug about how menus are displayed 5px from where they are supposed to be in a GTK app rendered on a X11-server that runs on the Windows desktop and see if the GTK developers care.
This one sounds so specific that I suspect you must have a reference to a bug tracker or a mailing list message somewhere. Do you? Having the context of the whole interaction is helpful when forming conclusions.
Without the benefit of such context, I'd suppose that the effort of reproducing the bug (not everyone has a Windows machine handy; the X11 server might be commercial or obscure) is a petty good reason for not giving it more attention.
The devs for the game factorio encourage players to post bugs on the forums. The devs use forums as a issue tracker and respond to bugs with fixes. I have no idea if that makes it more satisfying to report bugs or not, but I always thought it was cool.
Factorio also has automatic opt-out crash reporter. A lot of people in here are against opt-out, but once they added this years ago, they fixed tons of crashes which were NEVER reported.
The aversion to opt-out exists because it's associated with tech corporations tracking everything in a maliciously intransparent way, using some convoluted opt-out process as an excuse to give the illusion of respect for the user.
If a game just sends info about a crash I couldn't care less.
I disagree and think it should still be opt in. Crash reports tend to include memory dump which can easily include information about the system (environment variables) that the user did not mean to share. It's not unreasonable to pop up a dialog before uploading crash reports which also gives the user an opportunity to optionally add additional information.
In contrast, I stopped submitting bugs there because a forum is a terrible place to find and track bugs. Shame because I knew they'd be fixed by an outfit such as Wube.
Yes, disappointing handling of the bug reports, discouraging that person from doing bug reports again for anyone.
As a submitter, you can decide to invest in someone's detailed bug report form, including attaching screenshots, etc., maybe taking an hour or more, and derailing the work mental mode you were in.
After that work, what you learn most likely happens next is one of the following:
* Silence.
* "Yes, that's a problem." Then silence.
* 6 months later, automated email saying that this bug is automatically closed, due to inactivity.
* 2 years later, automated email that they've done a new release, so they've decided to throw away all open bug reports. But if you still find the bug in the new version, you can file a new bug report, they graciously offer.
* "We know about that bug, but we aren't going to fix it." For reasons you don't understand. And if there's a cultural mismatch, the tone can come across as hostile or disingenuous, besides.
* "This is a duplicate of bug X." It is not.
* Closes the bug report suspiciously, perhaps for optics or metrics.
* (Silence FAANG Special Edition: A high-profile bug report, on which tens or hundreds of knowledgeable people are adding on, for years, all saying this bug is a huge problem, and many asking in the bug report comments why is nobody from the FAANG even acknowledging this bug report in their own bug system.)
Suggested practice: If you ask others to invest in reporting bugs (by having that bug report form there), then follow through in good faith on the bug reports you receive. (At least on the bug reports that seemed reasonable, and that invested effort in your process.)
I ran into a bug at work where an app would crash and I’d get prompted to submit a report. It would happen several times per day. I often question how many bug reports I should submit for the same issue, and how detailed I need to be with each one, if the information has already been sent. I probably sent at least 40, hoping they’d fix it just so they wouldn’t have to hear from me anymore. Some were professional and helpful, others were mostly empty other than the log they generated, and others were a bit unhinged where I simply vented my frustration over all the crashes. I don’t think it was ever fixed, I just eventually didn’t need that software anymore.
The number of times I’d google my problem and find a ticket from 6+ years ago with dozens of users participating in the comments, confirming it’s a consistent, common problem, and not a peep from their devs.
It’s like their public issue tracker only exists to insult their users.
Apple doesn't have this. They're super successful. I hate it! But, clearly that's not an argument most bean counters are going to care about given such successful companies have some of the worst feedback mechanisms.
Apple has one of the most public support community[0]. You can get workarounds for most of the bugs, but never from official devs. Even hours old post has dozens of replies[1].
Same experience. Not even a tech person but I have reported obvious typos a few times. I think I got a thank you letter once and it was two months after I reported, that’s it.
The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports, or the "my neighbour is a spy for the government and I have proof" reports (real types of reports for a browser company, for example, which surely exist for other places users think that "is" the internet like Facebook).
I agree that reporting bugs can be hard, but the amount of spam that follows an effective open form, of craziness to uselessness, outweighs the useful bug reports.
Having two types of reports: one which is a simple screenshot taker with the ability to draw a circle over what is wrong, and one which is a more detailed report, would be useful.
Some LLM that filters out what is a useless report be a useful report would be good, too.
With all due respect, That is the price you pay for your users doing _free_ software testing for you! We are on the “listen to your users” mecca and you’re complaining that listening to your users is hard and you wish a machine could help you with it.
>for your users doing _free_ software testing for you!
In comparison to _paid_ software testing, which doesn't change the point at all: if they were paid to find bugs, they wouldn't be paid for useless and unactionable reports.
>you’re complaining that listening to your users is hard
Sometimes - and I'd wager most of the time - they are, yes, unless your product solely attracts technically competent and advanced users that can attempt to understand/reason about what is causing the issue.
> you’re complaining that listening to your users is hard and you wish a machine could help you with it.
That's entirely the wrong take, IMO.
Listening to users is easy, but the users often don't say anything when they speak. Those non-reports are basically spam that should be automatically thrown away.
When a mozilla application crashed it'll ask you to leave a comment to try and help resolve the issue when it prompts to send crash info, and you used to be able to see all those comments on https://crash-stats.mozilla.org (it seems to be behind login or restricted access now). There was a lot of vitriol and unhelpful comments that any developer would need to wade through to get to anything to give them a lead
If I'm writing FOSS and someone asked me that, I'd just reply with ¯\_(ツ)_/¯
I'm not making money from it, so trying to convince some random individual to use it is a waste of my time. Sure, I'll describe the features in the README and possibly include comparisons to other software, but I won't go out of my way to convince a specific rando just because they asked.
I think a lot of people here seem to totally fail to understand the user's perspective. Reporting on bugs is hard, because adding actual, helpful context to a bug is actual (free) labour. Yes, filtering out useless reports is hard for you, but that's the price you are gonna have to pay for having people do free labour (you get some unhelpful reports). You want to increase signal-to-noise ratio by focusing on decreasing the noise, whereas you should actually focus on increasing the signal.
Making simple, useless bug reports is easy and it will always be the easiest. Also the "my neighbour spies for the government" types will anyway always be the most motivated ones. There is no way to make it hard for "bad" reports without making it harder also for useful reports (barring some obvious cases of bots, ip filters etc, which are not what is discussed here and are a general problem not just for bug feedback). By trying to reduce the noise, you also reduce the signal thus get a worse SNR.
The specific tool is smart in trying to increase the signal. If you make it easier for users to add some useful context, MAYBE you get more users actually giving you sth useful, maybe even users who otherwise would not bother to add anything more useful than "it does not work".
I use software that recently made much simpler to make bug reports and add context, and they say they actually receive much better bug reports after. And most importantly, the users actually see that the bugs get fixed, which motivate them to make more, and more detailed, bug reports. Imo getting bugs fixed (and maybe even recognise the users' contribution in reporting them) is the best way to get good bug reports. Honestly, from my user's perspective having my feedback taken seriously is the best motivation for me to continue submitting reports. Because, honestly, sometimes bugs come up in complex situations that may be tricky to understand/reproduce, and it is hard to understand what context is relevant. I am not usually motivated as a user to spend like 20 minutes figuring out exactly how to reproduce a bug, but if I see that the company/engineers actually care and try to make it easy to me to report to them, I may actually do it.
Yes you are gonna have bad interactions also (and remember people have their own jobs/lives/not enough time to always engage with you the way you may want them to in providing feedback), but the point is to increase the good/useful interactions (compared to them), not decrease interactions in general. Unless you do not care much about bug reports anyway, that's also fine.
> The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports
This so much.
I can't tell you how often I've seen someone trying to get tech support on something say "When I load the program, I get an error" but don't even say what the error says. I understand that most people have never worked a QA job and so don't know how to write a good bug report, but certainly I would expect someone to copy/paste the error message.
> I would expect someone to copy/paste the error message.
If you're talking about non-technical users, they (a) don't even think of copying the error message, (b) don't know how to copy the error message, and (if the error message isn't directly copyable) (c) have no idea how to do a screenshot.
You're lucky if they even say that. Many public bug trackers I've seen are just filled with spam, entitlement and anger, demands/threats, or incoherent fever dreams of very unwell people. Forget about getting logs or reproduction steps. When you open bug tracking up to the public, you're lucky if what you get back is even remotely serious.
It's weird seeing people without computer familiarity using one, it feels like they are blind, they click in a button with a label and a icon, and when you ask todo it again they can't find it(even when you literally tell them the button name), it feels like their vision FOV is limited to a few centimeters, like those horror games flashlight lol, it's my own experience, but yeah, they aren't going to remember the error, or don't even read it, imagine print screen it before clicking "ok"
What's worse is how much the modern world and software quality has trained them to just be so helpless.
My mom has been using Windows computers since before I was born. She would spend all sorts of time working on the computer, creating tests for her classes, researching my sister's illness on the pre-2000s internet (with great success even!), had no problem adopting software over the years as things upgraded and changed, had no problems pivoting to using a Macbook at work, had extremely few problems adapting to remote learning, to the point of asking me for advice using OBS to improve her ability to run a virtual classroom (for things like different "scenes" and control over her output video). She broadly understands the concept of "files" and directories and how to move them and transfer them and manage them well.
But at some point, she forgot how the "Start" menu worked! You put her at a Windows desktop and she doesn't know how to start the program she needs to use! Do you know how much goddamned money Microsoft spent ingraining the start button in people's heads in the 90s?
But it's just gone. Because modern web based stuff follows no patterns. It makes no sense. Shit just happens sometimes, with no feedback, with no warning, and sometimes breaks while only leaving a damn error message in the javascript console, and the behavior changes from one day to the next. The only way people who aren't experts can hope to navigate this hellhole is to learn EXACT workflows and never change them and never think of changing them and never attempt to do anything novel in case it breaks everything without warning and don't pay heed to any dialogs because they don't contain useful info anyway.
Like, what did we expect to happen when we punished people for trying to build mental models of this stuff? You cannot build simple mental models of webapps. Companies don't want you to, because then you might not be as bamboozled and you might be less susceptible to advertising.
Yes, and some of the details really need to be emphasized, because I'm sure that a good chunk of people assume this means "people don't read more than they need to / people have a lack of inquisitiveness and general competence matching their lack of interest in reading for personal fulfillment" or whatever.
No, no, this is literal and (almost) not exaggerated. They _don't read_. Anything._Ever_.
The almost-not-exaggeration is in the "ever", if anything, because some of these people can eventually be compelled, with much sighing and gnashing of teeth, to actually read something.
But as a matter of course, they don't read. And that's not just "don't read what they don't need to." It's more like, you know how your eyes happen across some text and you just read it inadvertently? And your daily life is full of moments where these glances at random words give you little reminders or flashes of insight or just fuel for the train of thought? Haha, that's a good one. I didn't even do that on purpose. Anyway, they don't do any of that shit, they literally have to start reading on purpose and the rest of the time, as far as I can tell, they are actually not processing any of it at all. They navigate the computer/phone by rote or by visual cue based on color/position of UI elements. When they can't figure out where to go using that method and you suggest that they actually, like, read the shit on the fucking web page they're trying to navigate, they ...
... start at the top left corner ...
... and crawl the page elements linearly ...
... and when they arrive at the correct one ...
... there's a pretty good chance that they won't actually recognize it as such, because for some reason they simply can't contextualize any of the shit they're reading!
These are people who have jobs and social lives, are not wards of the state, and can carry on a coherent, reasonable, and engaging conversation with you.
(No shade thrown to visual thinkers though -- there may be some overlap, but I don't run into these people as often as I run into visual thinkers, so I think I'm talking about something else)
Whenever I saw statistics about literacy rates in the USA being startlingly low, I never believed it.
But then I remember many interactions I've had with people while working with the public, and...yeah I believe it.
You're right. People simply don't read. They don't even notice there are words somewhere in their vision. I used to work at a water ride at a theme park, and people would ask if they'll get wet on it, and there would literally be a sign right next to me that said "You will get wet on this ride, you may get soaked".
And then, occasionally, I'd have someone read it out loud, slowly, "you...will...get...wet..." and then be like "I don't understand, will I get wet on this ride?" and they're not even joking. They can turn the letters into sounds and words, but can't comprehend the result, yet if I just repeated exactly what the sign says, they understand it fine.
Now I wonder how many people that struggled with "word problems" in math simply weren't literate to begin with.
On the LLM idea, if you could group reports by issue (by parsing the user provided input and whatever context you save from the page screenshot into some embedding) and then only escalate things when several different IPs have reported a similar thing within X amount of time, I think you could handle two birds with one stone. Limits how annoying spammers can be, and also makes the good reports easier to understand since a few bug reports combined should make a better whole.
I however wouldn't shorten/transform reports with an LLM, or make spammy reports inaccessible. Just doing the semantic grouping for escalation. It's true you're getting free work from your users, and the human factor is pretty important here, even if an LLM might sometimes misinterpret it.
> "page doesn't work" with no further explanation reports
It cuts both ways. Guess what's one of the most popular format for apps and webpages to report failures to the user?
"Oops. Something went wrong."
Not exactly overflowing with useful information, either.
Sure, the system is probably logging the fault internally, and is always collecting metrics that help with contextualization later. But the system and its owner aren't usually the ones most affected by any given bug - it's the user who is. The user who's now worrying whether it means they're about to lose the time and work they put in the current session, or whether the app just ate their money (failures half-way through payment processes are the cutest, aren't they?). They don't know - maybe the "Oops!" was just benign, or irrelevant. Then again, maybe they've already lost it all 10 minutes ago - back when the previous "Oops!" briefly flashed to gently inform them that the service's back-end tripped over itself and died - but they won't discover that until later, at which point they'll be neither able nor willing to make a proper bug report.
Point being, if one sees their users as being 5 years old (but with parents' credit card in hands), one shouldn't be surprised to only ever get a kindergarten-level error reports like the ones you mentioned[0].
This is not just me complaining on a tangential issue - I believe showing specific and accurate error messages improves the ratio of useful error reports. It's not a full solution, but it's a step in the right direction. Treating them as partners, instead of a bunch of brats you have to put up with until they complete the payment, makes them more willing to reciprocate; giving users means to contextualize their experience allows some of them[1] to understand what's going on, and gives them something useful to put in the report too.
That, or I guess nowadays you can also keep the "Oops."-es, double-down on telemetry, and feed the metrics to a SOTA LLM to identify and interpret failures for your engineering/operations team, which we all know has neither time nor patience to do it.
--
[0] - "Page doesn't work" is the adult version of a kid suddenly starting to cry for unclear and possibly non-specific reason.
[1] - Obviously, not all, or even most. Software is complex, most users still behave as if half-drunk and unable to read, etc. Still, even 5 year olds can comprehend basic words and identify patterns. Figuring out that "could not connect to payment gateway" is serious, that "failed to write [blah blah tech terms]" that happens at random is probably not, etc. is within the cognitive reach of most users.
Yes, I love it. How helpful! I'm so lucky to have such a meaningful error message to Google. Now I only have to blindly try a list of 50 possible fixes before I discover that I couldn't save a replay on my XBox One because the disk was full.
Naturally, the stock counterpoint is that this happened because users thought real error messages were too scawy! :(
Most companies don’t have a user accessible way to file bugs. Often, you have to call support, speak to a muppet, then convince them that your issue is real and they’ll file it. Trust me, I find bugs in products all the time and I actually try to file bug reports, but it’s rare that I can.
Some of this is because one of the worst bug-related metrics is “customer found bugs.” This means that your developers missed it during unit testing and your test team missed it during system and final testing. Nobody actually wants customers to be able to file bug reports because they make the team look bad.
> If you've ever had a user say “something’s broken” and then ghost you forever, you probably get where I’m coming from.
As a consumer who reports bugs, I’d actually say the opposite problem is just as common — when the company ghosts you after you’ve taken the time to report an issue.
I’ve lost count of how many times I’ve used the official channels — bug trackers, support forums, contact forms — only to hear nothing back. No acknowledgement, no follow-up, no notification when it’s fixed. Honestly, I don’t think I’ve ever had a company let me know that a bug I reported was resolved.
Reporting a bug to most companies feels like sending a wishlist to Santa. That’s why many people don’t bother. They assume it’s a waste of time — and most of the time, they’re right.
Personally, if a company fails to engage over a bug report, I don’t waste my time reporting anything else. In many cases, I just move to the competition. I’m sure I’m not alone.
If a user goes to the time of helping you fix your software, the least you can do is spend some time on them.
Having run engineering teams for some reasonably popular open source products, my experience is that community reported issues can easily out-pace engineering capacity.
For every user who reports a clear, reproducible defect, there 10 others who report non-reproducible issues, who conflate features with bugs, who ghost, who use issues for support or questions, who are just angry about something and think you're an idiot, who report (since fixed) defects against old versions, or who report duplicates to existing issues. It's a very noisy channel.
It can lead to a crappy outcome for both the reporter who earnestly tried to help and for the developer who wishes they had the time to carefully address every reported issue but just don't.
Sometimes, all that's feasible is making time to triage/acknowledge each issue in a reasonable timeframe and to be forthright about its prioritization.
As an aside, I find your opinion that "if I give you my time in the form of a bug report, the least you can do is give me your time" to be common. We rarely have the right to demand another person's attention, though. Especially with respect to non-commercial open source hobbyist maintainers.
> Having run engineering teams for some reasonably popular open source products, my experience is that community reported issues can easily out-pace engineering capacity.
The solution to that is to have an additional triaging capacity. That can come from the community if you empower them with e.g. a public bug tracker.
If you truly do not have enough capacity to even fix the valid bugs then you have much bigger problems and no change to the bug reporting mechanisms will help you.
> As an aside, I find your opinion that "if I give you my time in the form of a bug report, the least you can do is give me your time" to be common. We rarely have the right to demand another person's attention, though. Especially with respect to non-commercial open source hobbyist maintainers.
This discussion is in the context of a post about a getting users to report bugs. Users might not be entitled to a response to their bug reports just because they spent their time but you sure as hell are not entitled to users telling you about issues encountered with your software before they inevitably get fed up and move to an alternative. The point is that if users feel they are wasting their time they won't bother - and the first to go will be the high-effort bug reports with useful information.
And this isn't really different for open source hobby projects - as long as you care about improving your software you'd do well to not make users who are willing to make good bug reports feel unwelcome.
Yes. I have built effective programs that empower community triage and committers.
My point is that a minority of issues to publicly available issue trackers are high quality (or even actionable - beyond triage), despite everyone thinking they are only posting high quality issues.
> you sure as hell are not entitled to users telling you about issues encountered with your software before they inevitably get fed up and move to an alternative
Reporting bugs is work, and is a two-way street: if submission is a black hole (possibly with some scripted replies from someone uninvolved in fixing bugs), then bugs will not be reported.
2) a reasonable response that may or may not include resolution
3) a shared debugging journey that takes three hours of my life
Number 3 devs mean well and have admirable commitment…but I’d rather not sign up for an epic trek to throw a ring into mountain doom. I just want to point out an issue and provide some basic info.
So these days the only thing I do for the most part is send crash logs.
A couple of years ago I played PUBG which crashed occasionally. I rarely submitted bugs, even if it was as simple as pressing a button in the crash reporter. This is because sending the bug report took a while and blocked you from restarting and rejoining the ongoing game. This applies mostly to multiplayer games but if your app has a crash reporter, give the user a chance to restart the app and report the bug later.
The opposite would be something like the bug reporting system in Second Life by Linden Labs (an online world where you can be with a virtual avatar, doing stuff) (at least way back, i dunno if they still have that open).
They had a public facing jira open, where people could file bugs and what not about the viewer (the client) and the world (the server).
You didn't need some special account or something like that, just your normal Second Life account was enough to get access to that one.
Drawback was, you were able to see what happens when filing bugs is easy. Of course, many people used it to file real bugs but also complained about stuff not working like they expected (or how it should work according to them, which brought other people up against them and so on...in the end you were able to read the latest drama here and there, right in the jira entries).
Although, to be honest, i thought it was an awesome idea, but you when you open up an easy way for people to report bugs, you need an easy way to explain what bugs are and what not. :)
Just this week I was working on something similar but specifically for users who have disabilities, so they can more easily report issues to site owners. I also combined general annotation capability so other users (of my browser extension) can read their comments. And also compatibility with Hypothesis (https://github.com/hypothesis, https://hypothes.is), also using the W3C Web Annotation spec.
I hadn't thought of the drag-and-drop bug metaphor; I like it.
I had also considered recording mouse and keystroke events up until the time that the bug is marked, and then bundling those events (sanitized) with the bug report for more precise repro steps, but of course that's a bigger ask for the opt-in.
As a user the best thing you can do to make me report bugs is to show that you are actually going to fix reported bugs. Taking my time to gather information that will effectively end up in /dev/null is the opposite of fun.
Also important is to let me make sure I don't waste time reporting something that is already a known issue.
The best way to do this is to have a public bug tracker.
Given these preconditions acceptable effort only depends on how invested I am in the product.
In 2022 and 2023, I made a push to find and fix bugs in OpenZFS using static analysis tools. I found many obscure bugs. One was a theoretical issue that should have affected big endian systems and been an annoyance for users, but there were no bug reports saying anyone had been affected. After I opened a PR with a fix, people told me that they had been affected, but did not think it was worthwhile to file a bug report. This surprised me. This is the PR:
For many corporations, there are probably perverse incentives against making it easy to report bugs.KPI of reported bugs as an indicator of software quality, for example.
It's not just a problem in the corporate context. Open source projects usually make it a pain in the ass to submit bug reports too, in a clear effort to gatekeep the process to experienced developers. Simply because developers prefer to only deal with other developers and don't want to hear complaints about their software from the unwashed masses.
Certainly seems like there must be some KPI against fixing the bugs. You can look to any big tech software and find oodles of long standing bugs which never receive attention.
I really like how some indie games have put in a widget for feedback. Press F11 or something, click an emoji face, optionally add a description, and click send. The game takes care of sending a screenshot, game state etc. (It tells you it's doing this in the interface)
Totally get this. I once spent days trying to get users to submit decent bug reports through a fancy form and got almost nothing useful. The moment we switched to a simple “click here to report” button with an optional note field, the volume and quality went way up. Simpler is better, especially when the user is already frustrated.
Any involvement in reporting / fixing bugs is development. Why do app developers think their customers need to be or want to be developers?
What other industry relies on its customers as implicit developers?
Making bug reporting easier means an intentional push to foist more of Development's work upon customers and a bias towards more bugs.
BUG OR FEATURE?
If you can't tell, then we can understand why Knuth call it "the art" of computer programming, as in the artist's uncertainty of creation as compared to the engineer's confidence.
The fact that half the SW industry prefers to avoid a distinction between bugs and features— as in bugs that don't get reported are regarded as features— shows the profligate laziness and opportunism of so called Software Engineering.
AI is a stunning example of a global industry built by computer technologists who don't care about understanding their own work, and lack the creative and social spark to conduct themselves as artists.
Just listen G. Hinton babble philosophically for 10 minutes and you will grasp the magnitude of incompetence at work.
I think reporting problems is just part of being a good citizen that participates in a shared culture. If I visit a park or shop and something is broken, it's worth putting in a bit of effort to report it. If everyone chips in a little bit of effort it makes the overall experience of everyone much better. Are you the type of person to also not return the shopping cart to the corral?
The number of hardware and software combinations are impossibly large, so you're unlikely to be handling everything perfectly if the application is doing anything complicated.
> What other industry relies on its customers as implicit developers?
I would say most of them. To list a few:
- restaurants (almost all of them will send you feedback surveys these days, they also rely on you to tell them if they, for example, cooked your steak to the wrong temp)
- property maintenance (again, feedback surveys)
- auto mechanics (if the thing they fixed is still broken, a good mechanic wants to know)
- doctors (they rely heavily on YOU to tell you what wrong with your body)
- democratic political systems (when working correctly)
- road infrastructure (the city won't fix potholes nobody is reporting, and they won't do anything about badly tuned traffic lights nobody complains about)
- vaccines and medicine (the testing phase may not uncover every possible single side effect, they need recipients/users to report those if they happen)
(Please nobody come back with cynical takes on how these aren't helpful in their specific case/location, that's clearly not the point)
I think it's a given that I'm not using perfect metaphors, dissecting them is ignoring the point.
Users operate with different configurations, hardware, and needs. It is literally impossible to release bug free software. Every developer should try their best, obviously, but NOT requesting that bugs be reported is pure hubris on anyone's part
The unfortunate situation is that bugs in modern software just seem to… show up, as if their appearance is an ongoing maintainence issue rather than the outcome of something somebody on the development team did.
But, anyone who took the time to write bug-free code went out of business decades ago.
> Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects.
Maybe people could combine this reporting solution with a bug capture solution I built a few weeks ago? It's a web-based screen recorder which allows a user to gather together several different areas of the screen into one place, add a talking head of themselves and demonstrate/explain the problem they've encountered. The resulting video could be added to the bug report. I built the tool because showing the problem is always better than trying to explain it in words.
When I encounter a bug, I will almost never report it either, I’ll hope that someone else will or the developer will notice themselves while using their product.
Reporting a bug is work. If it is certain that the bug will be fixed upon reporting this work may be worth doing for selfish (or non selfish) reasons, but I almost never have confidence that it is.
I stopped reporting bugs when projects started to deploy bots that close "stale" bugs. No, someone ignoring my issue for 3 months does not imply issue went away.
I was cool when bugs waited for proper prioritization 6 months later. Ok, it took time, but someone is busy. When they are getting closed automatically, there is no reason to bother.
I don't know if this is the case now, but about a decade ago, in order to report a Bug to Microsoft you had to create a Premier Support ticket, which cost $1000+, but free if it's a Bug. So basically, if what you report is not a Bug, determined by them, it's treated like a Tech Support ticket and no longer free. I recall discussing this with a representative and let them know that I'm basically doing them a favor by reporting the bug -- why would I want to take the chance to possibly have to pay for it if they happen to determine "it's not a bug -- it's a feature". I got the standard corporate-speak answer which I just waved off as ridiculous: "Look, we will absolutely not charge you if it's determined to be a bug"... :|
I've since have seen Microsoft use User Voice and the products (at least Visual Studio) has a great way to give feedback to the team, something I've used multiple times, including for feature requests. And of course, for their Open Source products, they have Github Issues, which is awesome.
“Stupidly easy” is bad copy imo. I honestly did not want to scroll through the front page after seeing it. In a sentence it does not have nice flow and from a business perspective it feels immature. I would tighten up that copy a lot but that is just my opinion. Also, might be in the minority but I avoid any products that put ProductHunt flags on the page, especially prominently at the top.
I had a lot of success adding links and buttons to report bugs on error pages and messages. Doing that while whatever abnormal state led to the message is still hot allowed me to gather a lot of information about the state of the application to be attached to any bug report. Initially I used the Macintosh bomb icon for it, but some users found that too cryptic compared to a text message.
2. The site days 'try bugdrop' and points to the left bottom corner.
3. I click the bug. Nothing happens.
On further inspection, there is sometimes a tooltip that tells me clicking won't work and I need to drag the bug over the part of the UI that failed, but I didn't read that when I first used it and I won't use it a second time.
Thanks! Pardon if my feedback sounded direct, I wanted it to be impactful. I’m imagining somebody will click on the bug, you will show them very visibly that they need to drag the bug to where they need. When they drop it, they can fill in the form or move it somewhere else.
I'll report bugs, give details — via multiple cumbersome steps, iff I can clearly track the status, follow up. Otherwise, even a one-click “send report”’popup isn't worth my effort. This is why I no longer bother reporting anything to Apple. Same crashes/errors keep on for years. I’m convinced those reports go to /fruit/null.
I won't report bugs in paid software/services because it's not my job, I'm not paid for it, I'm user of the service, not free workforce so they can reduce amount of QA staff or skip it completely. Give me a discount and then maybe, just maybe I'll think twice about reporting something.
Bugs renders your soft unusable? Fine, there is plenty of competition out there who will do it right.
A clickable link with a form (partially pre-filled) and a big banner that says if the bug is verified I get 10-25% off something AND a followup email (reiterating the offer) + tracking link, would motivate most people I know.
I've worked with people who uttered this phrase many times. You really should put this on your CV because it's an incredibly helpful indicator of character trait.
I tell my customers that they should spend 1hr per month “improving the vendor”.
See, if you rely on a vendor, then you need them to survive. It’s a parasite-host relationship. You need to tell them what you need, and oftentimes they will bend the roadmap in favour of the most demanded features. Alternatives:
- They choose their most amusing feature,
- They choose the most lucrative feature among the new possible markets while ignoring all bugs, which is the most rational way to address bugs unfortunately,
- You don’t tell them, they don’t improve, they die / they triple the price of the product by lack of audience, and you have to migrate your data to another product.
Nice, I hope you are spending 1h per month for each customer as well advising them how the can get the most out of your service and/or improve their integration - otherwise it would seem like you are expecting unpaid work from your customers, which is ridiculous.
I hired a house cleaner. I didn't tell them what to do because figuring that out is their job. They didn't do the things I wanted and they even missed some spots on what they did do. I didn't tell them about that either. It's they're job. So I fired them and switched to another. Repeat. Maybe eventually one of them will figure it out.
You hired a house cleaner, you told him everything he needs to know, he did a good job. Next time unfortunately he arrives with broken vacuum cleaner, he has another one, smaller, less powerful takes him longer to do the job but it's still done, not spotless but it's fine, he is a nice guy, has good attitude.
Another time and he arrives with faulty steam cleaner, again , work is done but takes longer, not ideal outcome. This is happening again and again, he even asks you sometimes to wiggle the cord, push some buttons and try to troubleshot, you know, improving the vendor and stuff.
Maybe adding a clickable/highlighted actual url in the post to make it more stupidly easy to go to your website, if not on the title itself (not sure if you can add that now) could also be a good idea. For stupid people like me that spent more than 10 seconds after reading it trying to figure out where I should click.
I have a bug in my Honor (200 pro) phone were after some time, whatsapp's notifications with no sounds are changed by the SO automatically to Gentle Notification (no popup, only number on icon) I want to have a popup, but without sound.
I might have reported several times, well, they have not done anything about it.
I also reported something to Lutris just to be told, not our problem wont fix. which is the same feeling of, why have I bother doing this.
And after a few of those, if you have a bug, you moved on. In this case I regret going with Honor instead of Samsung, and it would be likely the last Honor phone I got and I do not recommend to anybody. And with Lutris, I would rather use windows and be able to see my screen instead of a black box when logging into epic.
If you don't fix the bug, the user will stop reporting, and will find a workaround.
I think it's cool you built and shared it - grats on shipping.
But you (or your users) are about to learn a few truths about bugs and users :)
Foremost: unless your users pay for the product, there's a downside to easy bug reports - the vast majority will be useless, no matter how easy it is. Granted, that's true for paid products too, but at least you can bake the cost for dealing with that into the price of goods.
It's absolutely great while you're building traction. Even the most inane post has usually a kernel of truth. It's becoming a problem as you are clear on where you're heading, and the cost of dealing with them outpaces their value.
At that point, you either start stochastic sampling (annoying your users who write well thought-out reports, and who are your multipliers), or you spend a fortune to slog through everything. That's when you start writing the "feedback suite" backend :)
For me the most fatal part of the big report loop is where you report a bug, and get radio silence, or a curt dismissal, and the bug lingers on.
Telegram for MacOS has a bug where it will occasionally crash when you try to delete something. I reported it nearly 2 years ago. It's yet to be fixed
On the flip side, I got some of Fireboard's pulse probes last year, and had an issue where they wouldn't connect to my Yoder smoker. Quick ticket and some easy debugging steps I was able to do more or less asynchronously, and a cause and fix was found: the Bluetooth stack on the smoker would crash after a while, so unplugging the smoker when it wasn't in use was an easy fix. The bug still remains in the firmware, but there is a solution that works for me, and so I'm happy with a functional product, while I wait for the firmware update
Not potentially a customer because I have very few users that I can track if one of them have issues. So take my suggestions a bit lightly
1. I'd rather have/use a npm package then your minified/package script. You are not Google, so I am going to need some trust there and that happens by making this an open source package.
2. If I am going to implement this on my site, I'd not use that little bug. I'd rather have this custom design/integrated with the rest of my app. So provide API/functions/Hooks to use your library.
3. I'd never consider a one time payment (lifetime subscription) SaaS. That screams: I am going to take your money and disappear in a few months. Also, any product that doesn't have clear bandwidth quotas is probably missing in disclosure.
I strongly recommend going a lot less heavy on the LLM generated writing on HN, it reads far less genuine than when people here right stuff themselves.
Just in case you think it's the em-dashes that do it, it is isn't; it was clear by the end of the 2nd paragraph.
This looks an awful lot like all the "contact us" forms that are mostly broken and give you no feedback as to whether the message got through or not. At least it's easy but you can bet half the sites that use it won't even be receiving the reports, let alone acting on them.
In my desktop app, I ask users to email me in a global exception handler. My thinking is that they'll recognize that I don't want to be inundated with reports for the same bug over and over so they're probably the first to find it and it's worth reporting. And I do fix them all otherwise I would be getting spammed by the same reports over and over again.
If you submit a really detailed bug report, such as one where the problem was reproduced under a debugger, it becomes a "the reason you suck" speech. This really upsets some dev teams. The usual responses of the "turn it off and on again" and "reinstall" don't make the complaint go away.
There are two bugs in Firefox I'd like to report, but it's futile. One is that, launched on Ubuntu, Firestorm does disk I/O for about three minutes on launch. During that period it can't load complex pages, although it loads ones without Javascript fine. The other, again on Ubuntu, is that it freezes when large text boxes are being filled in. This only happens on some sites.
I feel like on windows there's similar issue - after crash (force close) Firefox will load UI fast, but spend several minutes to not show black screen instead of websites in my session
I remember finding 3 year old reddit post about this, and I have no idea whether the bug got into normal reporting place (where even is it?)
I love the UI concept. Being able to point at a broken thing rather than try to uniquely describe the position/state/path to a broken thing is smart!
Hooooever, "bug" could be a bit ambiguous to a lot of people. Looks like in a real deployment, you have a little tooltip that says "Spotted a bug? Drag me there!". That makes sense to developers and the like... but those are also the sorts of people most likely to write a good bug report anyway. The people most unlikely to write a bug report are the sorts of people who will read "spotted a bug" as "there is an insect... game?... on this site?".
"Issue" or "Problem" would be better, but keep the bug graphic! It's cute. :)
When I took a look quickly, it also shows the "Spotted a bug? Drag me there!" every time the page loads - which could quickly get overwhelming, and make the user wonder why the developer is so certain that they will run into a bug. (Why do developers not make "report a bug" obvious? Because just seeing it implies there are enough bugs that a link is necessary.)
I also have no idea how well this works on mobile - and seeing that the Pro plan doesn't remove attribution seems like a mistake.
I agree - the attribution needs to be removed for paying customers, or at least for me to want to pay for it to use with a client.
The phrasing should be customizable. Even better if the bug is an SVG and I can paste in my own SVG for the bug icon.
I was worried about how it worked on mobile, and unfortunately on my iPhone I could not find a way to drop the bug where I wanted. It did show a popup eventually but it covers a lot of the page given it doesn't work as expected.
Just sharing thoughts/observations; I really like the concept as well.
Hey graypegg, you're right about this. I'm thinking about changing the wording of the popup to something like “Something’s not working” or “Spot a problem?”
This is a huge problem in Apple iOS land where the only way to leave feedback and tons of apps is to leave a review on the app store and then watch Apple delete it immediately
I spent a lot of time working in the user research space and the disconnect between what users told me and what they did was so huge that I just built an AI that watches user sessions and figures out bugs and friction. Works well for like 90% of cases
1. Is the little bug icon sufficiently visible? I'm not sure...
2. Do visitors automatically know what to do with the bug? You have a tooltip, but do all visitors know what "Spotted a bug?" means?
3. [more of a suggestion; perhaps it does this already] Would be great if the bug position pulled in a CSS class or the content surrounding the "dropped" bug -- to give more context to the site owner.
The first job I had as a software engineer was at a trucking company that had a desktop Swing application. If an exception happened, the user would get a pop-up with buttons to email support the stack trace or cancel. The email went to all the IT staff and someone would usually reply within an hour, often with a fix.
The engineering work was atrocious looking back. I probably fixed 50 random NullPointerExceptions in my 3 years there this way. But, it was one of the most productive places I've worked at because everything was done simple and there were no barriers between users and developers.
Your product is similar to one I own. I checked out your website. It’s good.
Unsolicited advice: you gotta charge more for this product. A lot more.
We charge up to $250/month or $3000/year. Some customers (companies you’ve most likely heard of) pay that, yearly in advance and have done for several years.
Working at google taught me to not bother. An android bug I filed the month that I joined was closed a part of "bug bankruptcy" seven years later, having never been triaged. Why bother? When I was quitting - a year after that, the actual bug still existed.
Yes! Similarly for text books, which are riddled with errors, generally speaking. They should have have an email address for reader-submitted errata printed in large friendly letters on the inside front cover.
Testing bugs is your full time job. Why should I spend my time doing it for, at best, free, but more likely pay to do so? And even then, the bug is almost always closed without fixing anyway.
Only thing I would add is after submit it should allow you to enter an email address or something so that (a) the user can get updates on the progress of fixes; and (b) be contacted if the dev needs more info.
The most I have tried with reporting bugs in a mobile app is going to settings and seeing if there’s a bug report button or something like that. Not worth the effort considering the low probability of it being even looked at.
Love this! That said, wanted to try it on your website, can't report a bug that the bug reporting doesn't work on Safari MacOS... the submit button does not do anything.
Built in fun mini game: How far can you get the bug to move (only counting after you release your mouse) without the popup appearing. Multiple clicks are allowed.
Here's a quick bug report: I didn't know how I can check out the app you built. There were no links in your post. Only "Bugdrop.app", the name. I tried Googling it and it turns out Bugdrop.app is your actual domain.
You should point that out: Bugdrop.app => https://bugdrop.app/
On macOS .app is the standard extension for any installed app.
The worst example I ever experienced was finding an actual flaw within some software with Trac as a version control system - somehow DD-WRT comes to mind - and I submitted a bug report with full reproducibility workflow and everything I could imagine. Essentially, the platinum standard for submitting a bug report in software development.
It was immediately rejected.
The reasoning? “Did not identify the relevant code in which the error occurred”.
Like… WTF????
Edit: confirmed as DD-WRT. I’ve never submitted another bug report to them again. And I’ve submitted hundreds of reports to other projects all over.
worse, support that is overly fixed on support sessions and calls to resolve bugs even when in the ticket it clearly states it's not reproducable, only a restart fixes it etc.
Take my logs and everything you get but ffs make it observable enough so that you don't waste my time.
Thank you. It's a simple setup—just copy and paste the JS snippet into your website. I'm also considering creating some video tutorials soon to make it even easier.
There's the other side of the coin of reporting bugs besides initial friction: if the user feels like the bug reports end up in a black hole, then they will disincentivized from doing so.
What happens after the user files a bug from their point of view? Is there a follow-up, or is it like throwing a message in a bottle?
I'm thinking of adding an option for users to leave their email for follow-up after submitting a report. That feature should be available in the next couple of days.
yes, Kate editor is a classic example. one clicks the report a bug link in-app and immediately gets a login page. no one has time for this sort of thing. it indicates a disinterest in getting bug reports, making people do homework to report one.
i switched editors and got back to work.
The first job I had as a software engineer was at a trucking company that had a desktop Swing application. If an exception happened, the user would get a pop-up with buttons to email support the stack trace or cancel. The email went to all the IT staff and someone would usually reply within an hour, often with a fix.
The engineering work was atrocious looking back. I probably fixed 50 random NullPointerExceptions in my 3 years there this way. But, it was one of the most productive places I've worked at because everything was done simple and there were no barriers between users and developers.
I love this, and I'm so glad it has resulted in more people filing bugs. That said, there is a larger problem going on here that has yet to be addressed by the software industry as a whole. And that is that "bugs" (and "filing" bugs) is a very complex thing. It's not just one thing, it's many, many things. And until we face that and provide a holistic solution for "it", it will continue to be an existential problem.
Here's a selection of the different kinds of complexity with "bugs":
- Type. Is it a backend or frontend bug? A network bug or an infrastructure bug? An internal or external bug? Is it a "not considered a bug" bug? Is it a bug in documentation, training, intuitiveness, etc? A product- or feature-specific bug? A location-specific bug? A user-specific bug?
- Context. Is the user even capable of giving you enough context and information for this bug report to be usable? If so, is automatic? If not, will the user simply give up reporting when this becomes difficult?
- Communication. How does the user even report a bug? (I regularly try to file bugs with every tech product I use - because they are constantly riddled with end-user bugs - but I spend hours trying to dig up some way to contact the company to report the bug, and when I finally can contact someone, they refuse to even take my bug report, because it's not one of the read-from-the-script-customer-service responses/actions. And if the user does eventually get in contact with the company, is the developer (or anyone else) even capable of communicating with this user to get more information or inform them of a fix?
- Visibility. Quite often, users will experience bugs, and maybe one report comes in about them. This is then captured by customer service or someone else, and maybe they file a ticket. But then for each subsequent request, they just tell the customer they will record it and then.... don't send it to anyone, because they've already sent one such bug and assume it's being fixed. So the developers have no idea how often this bug is actually happening. Often when bugs are reported the devs aren't informed at all.
- Impact. Is it just affecting a single user, once or twice, in a niche setting? Is it affecting the same user all the time? Is it affecting a subset of users? All users? Is it affecting all users, but core functionality still works? Is it significantly affecting core functionality? Is it affecting core functionality but there's bigger issues going on so it's actually less of an impact? Are the developers even capable of understanding the impact? (how many of you know exactly how much each specific function affects the business?)
- Prioritization. We all have ticketing systems full of hundreds of tickets that sit in the backlog never to be fixed. They're annoying, or difficult, or unsexy, or they're not a new feature. Sexy bugs get prioritized, unsexy bugs sit in the trash heap.
- Fixability. Even if all of the rest is provided for... how difficult or easy is it for a developer to fix? Is the developer capable of contextualizing it and making use of the information? Do some of them have difficulty reproducing it, while others don't? Do they have all the training needed on all the systems involved in order to effectively triage/investigate/troubleshoot? Are they given dedicated time each development cycle to fix bugs? Are they even able to track down who is responsible for "fixing" the bug, what with the modern mess of interdependent microservices and siloed development teams? Will they be implementing regression tests to make sure it doesn't come back? Are you rewarding them for this work, in addition to the rewards for "sexy work" (new features implemented, cost saved)?
Yes, getting users to file more bugs is fantastic! But that is quite literally the tip of the iceberg.
About 90% of day-to-day users won’t bother recording a video—plus, most people aren’t even aware of the browser’s screen sharing feature and may feel uneasy about what it’s doing. So in my opinion, a simple note is the best way to go.
You write that "reporting bugs is usually a terrible experience". I find bugs ALL THE TIME, and yet, when I even try to find a way to contact ANYONE, let alone a developer, they leave no door open at all. No method, no form, no contact name, no nothing. I (along with many, I presume), actually want those companies to excel. I WANT to let them know what to fix. But, they just don't want to hear about it. Really sad I think.
In my experience it's because the companies have not hired any persons whose job is to triage bug reports. People do find bugs all the time, and making it super frictionless to report bugs will result in a deluge of reports. Some reports will be outright spam, some could be mistaking a feature for a bug, some could be duplicates. Someone needs to do the triage and try to reproduce before the issue is forwarded to developers. Few companies have the role of Quality Test Engineer (QTE) to do this job; most don't so they have no means to triage the bug reports.
The only exception is indie apps I pay for on the App Store. There is usually only one or perhaps two people behind it, so by definition that person is SWE, QTE, PM and several jobs rolled into one. And this is unsustainable unless the app is paid.
Wait... Isn't that what AI is for? To do that for "free" and removing the time an actual person has to spend on it? Separating the spam and duplicates, etc?
The difficult part is the step of reproducing the bug. Will companies trust AI enough to allow the AI to operate on their UI, according to instructions written by bug reporters who are strangers on the internet?
I think if you take for example apps on the Atlassian Marketplace, probably all of them have an easy way to contact them (Probably because they get Jira for free, granted).
I develop for iOS and Android. All my apps have a Send Feedback button which opens an email in the user's default email client with my address in the To field, pre-filled subject line and some diagnostic info in the body (things like version number, device type, iOS version etc). I get all my bug reports and feedback that way and respond to them via a reply email when I have released the update to fix it.
I had really simple feedback form in my Android app that was just text area and submit button. Then some ashole tester from Google put @ in it and suddenly I'm collecting PII. It was easier to just remove the feedback form.
And that is why companies use telemetry. As privacy advocate I still let telemetry to be collected as long as it is transparent. And I can filter it if there is something too disturbing.
I use to report bugs all the time with details of the bug and what I was doing and if possible how to cause it. But then when you encounter the same bugs years later doing some very common task that you momentarily forgot to do your work around for, it made me wonder why I was wasting my time reporting it. These days I rarely report bugs unless it is brand new software released a few weeks ago at most, or a brand new release of older software with a new bug. If something isn't completely breaking the use case of a program, or doesn't have any viable work around, I just don't expect it to ever get fixed. So why waste the time? Im not getting paid for it, it likely won't be fixed, and 49/50 bugs I encounter are things that seem impossible to miss with any real QC.
Doing decent bug reports as a user most of the time it feels like following the turnip truck to town picking up turnips that fell off the truck, giving them to the farmer, but knowing they will likely be thrown in the trash because they didn't care about them to start with. If they did they would have made sure to not overload the truck to start with and not be obviously dropping so many turnips on the side of the road and leaving them there.
It depends on the company. I’d never dream of reporting a bug to Apple, they don’t care. I think your turnip truck analogy applies there. On the other hand, iA Writer consistently replies thoughtfully and usually fixes the bug.
It’s so important to treat companies individually instead of just according to some blanket impression of the world. Individual treatment means good companies benefit and grow, while blanket treatment actually actively rewards bad behavior: a company that invests in quality will bear the cost while you share the benefit with the competition, while a company that treats you worse will reap the savings while you take out your frustration on the competition, too.
Then there are the ones who send you a detailed response trying to convince you that it isn't a bug, when it definitely is one. I've switched programs over that, not because the bug itself was that important, but because I don't like running code that I've established to be written by boneheads.
Is this a reference to https://github.com/systemd/systemd/issues/5644#issuecomment-... ?
Hah lol, I hadn't seen that one. I was thinking of something unrelated, though it has happened to me more than once.
I submitted a feature request to Apple to allow silencing the ringer for anyone who isn’t in my Contacts list. A year later with the next major update, the “Silence Unknown Callers” feature came to iOS. It appears it worked, either that or it was just a wild coincidence. Of course many other feature requests I’ve submitted over the years still do not exist, such as a global toggle for explicit vs clean music (when it’s just me I always want the original version, but if there are kids in the car, I want an easy way to clean everything up).
I know someone else who has called Apple’s support line and spoken with engineers on bugs that were uncovered. He then got follow up emails to install the latest macOS update as it contained a fix to the bug he stumbled across.
Counter-anecdotally, I reported two WebAuthn issues to Apple in separate instances and both were immediately fixed in the next patch version of iOS/Mac OS. In both cases first line support had little understanding of the issue but were very good at following process, trusting me, calling me back to keep me updated, and escalating to engineering as necessary.
That’s security though, not mere bugs.
> I’d never dream of reporting a bug to Apple, they don’t care.
One of the few issues I’ve reported to them was promptly responded to and fixed, but that was probably because it had privacy implications.
I've done the same with Windows, but I had a unique bug with Storage Spaces and did some debugging to identify driver issues to include with the report. I guess the reason it was fixed was because there was similar feedback without the debugging on the Windows Feedback app and because the blast radius was small. It was just one .sys file, but even then Storage Spaces is relatively contained.
Compare that to any GUI-related issue. Almost every surface has some kind of unsupported/unexpected hooking or reliance on unchanging elements because some company has built a tool that integrates. They've then sold this to Fortune 500s who explode if Windows blows up their tool. This makes the startup cost for fixing many things very expensive.
If you report issues related to higher profile/usage functionality then you are less likely to get traction because:
* They know about the issue already, but it's a really hard to fix for some reason which may not be obvious to you. All stakeholders are not equal in the decision process hence compatibility concerns win in some situations.
* Even if they decide to fix it, a huge amount of effort has to go into scheduling the fix in a release. Some authority may agree to go fix it and everyone is excited. That's just the start of a painful process to implement and test the fix.
> If something isn't completely breaking the use case of a program, or doesn't have any viable work around, I just don't expect it to ever get fixed
Yep. That has always been the general industry sentiment [1]:
> Here’s another bug that’s not worth fixing: if you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn’t even use large files. Well, don’t fix it. Worse things have happened at sea. Similarly I’ve generally given up caring about people with 16 color screens or people running off-the-shelf Windows 95 with no upgrades in 7 years. People like that don’t spend much money on packaged software products.
[1] https://www.joelonsoftware.com/2001/07/31/hard-assed-bug-fix...
You missed the important part:
>But mostly, it’s worth fixing bugs. Even if they are “harmless” bugs, they may reduce the reputation of your company and your product, which, in the long run, will have a significant impact on your earnings. It’s hard to overcome the reputation of having a buggy product.
I wish that was the case. I suffered Crowdstrike being force installed upon all servers at a previous firm. After every system update it would "lose" it's configuration and proceed to try scanning every attached drive, some of which were in the petabytes. It's inefficient scanning process consumed 70% plus CPU and caused service outages for some users. Each time we'd ask for configuration to be added to ignore certain mount points, each time it would get turned on again. The only thing that saved us was distributing the service over multiple servers in different regions so that their updates were staggered. We spent >5% of team effort for a few years fighting Crowdstrike.
Just under a year ago they caused a global outage (https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...). I thought, aha finally they will pay for their sloppy software. Then I checked the share price today, it's up 20% in the last year. If a cyber security company can cause one of the largest global outages ever and go relatively unpunished, I'm not surprised some firms are not fixing bugs. Very disappointing.
I didn't miss it. That's the serious part, after Joel Spolsky sarcastically explains what companies usually do.
I've reported bugs in a few projects. In my experience, the smaller the team behind the software, the more likely your bug will be fixed.
I think I've reported bugs to Bloomz (the awful communication app my school uses), jpmonette/feed (the node/typescript RSS feed generation library), and I think at one point I reported one to Newsblur, and they all got fixed.
This has been my experience as well.
I submitted a bug report on Things To Get Me (an Amazon wishlist alternative) on a holiday weekend, fully not expecting to hear anything until at least Monday. It wasn’t anything too major. Within the hour I not only had a response, but a change was pushed to prod after a little back and forth with the developer.
A couple years ago I signed up for write.as and the founder/ceo reached out to have video chat just to see how things were going or if there was anything I’d want to see in the future.
Yeah... unfortunately this is how it is at my company which is a startup, I reported so many bugs that just got ignored and it can be demotivating to see the same bugs still in our app months later that could've been fixed in 15 minutes
I've had the opposite experience reporting a bug on Telegram. But it was a particularly thorough report (windbg and all) and if that's what makes the difference, it seems like an unrealistic thing to expect of most users.
The problem with bug reporting is that they rarely seem to get fixed. I used to do a lot more bug reports. But you often hear back nothing, and then the bug is never fixed, even if it would be an easy fix. These days, I don't often report bugs.
Some teams have a frickin' bad attitude and couldn't care less. Try submitting a bug about how menus are displayed 5px from where they are supposed to be in a GTK app rendered on a X11-server that runs on the Windows desktop and see if the GTK developers care. Or try telling the react-testing-framework folks that they're asking me to put handrails in my bathroom when my house is burning down. Have experiences like that and you'll conclude it isn't worth filing bug reports.
Now the linux-industrial complex is a special case, if you are a software engineer and know how to isolate a problem and submit a great bug report you will often hear from people who will say you sent them the best bug report all quarter. It helps if the team is working with web tech, younger, more diverse, and never heard of the GPL.
Don't forget all major OSS repositories using a stale bot to close any issue regardless of how many people reported it or how serious it is. Close and lock at times. Yikes.
I have seen OpenZFS adopt one, but whenever I have seen a bug that has merit closed by the stale bot, it is reopened by a contributor and a not-stale flag is added to prevent it from being automatically closed again. Note that I am a contributor, but I am not one of the ones who is reopening bugs and marking them as not stale. The few times I saw such a bug and would have done it, someone else beat me to it.
The stale bot approach does help in cases where a bug does not have merit. For example, not that long ago, a user opened a bug asking us to rename the ZFS Event Daemon so a text editor could adopt the daemon’s name. The consensus among contributors on the discussion is that we will not do it, but no one has volunteered to be the one to close the bug. The stale bot will be closing that one for us.
I think that once a bug has been verified and keeps getting likes, it should not be closed.
If the user never responded to further questions, then absolutely.
What I see however is that maintainers themselves fight the bot removing the label and reopening issues. Over and over. Until they miss the notification.
Once the not-stale label is set, the bot ignores the issue and will not close it again. At least, that is how it works for the OpenZFS bug tracker.
> The stale bot approach does help in cases where a bug does not have merit. For example, not that long ago, a user opened a bug asking us to rename the ZFS Event Daemon so a text editor could adopt the daemon’s name. The consensus among contributors on the discussion is that we will not do it, but no one has volunteered to be the one to close the bug. The stale bot will be closing that one for us.
That doesn't sound like an even remotely ideal way to handle that. Don't just needlessly string the original reporter along until some arbitrary time limit expires.
It should be obvious to him that it is not happening given that several contributors all responded no. As for closing the bug, no one has volunteered to be the one to do it.
If it isn't obvious enough for any contributors to close the bug the it won't be obvious for an outsider.
Mine were closed by stale bot. They had merit and reproducible example. I just was not stalking the repo, watching it constantly to keep it alive.
Which issue? I can reopen it and mark it as not stale.
Yep, stale bot got me to stop reporting bugs to Kubernetes, I spend time to gather details for an useful and it just gets closed without any human interaction. That's super disrespectful.
I stopped reporting bugs when I see the repo is using stale bot. One thing is to be ignored for a while, because maintainers are busy. Another one is to be told "we ignored you long enough, it is not an issue".
Yes it still is. I made a reproducible example, try it out.
Yeah if I see a bot like that I just don't bother with bug reports to that project. Absolutely disrespectful to not even bother having a human look at the bug to decide if it can be closed.
I once saw one that only closed issues after two whole years of no response. I couldn’t help but think that was entirely fair.
GTK is developed entirely by volunteers. None of the "rules" of bug reporting in this thread apply. If it's a business selling something to you? Sure, don't bother if they don't seem to care.
But with volunteer-driven FOSS projects, what you want as an end user is much, much lower on the list of priorities compared to a business product. Even if you have implemented the "fix" [1] yourself, they might still not accept it unless you're willing to stay around and maintain it yourself. And that's perfectly fine.
[1] Assuming that the maintainers agree that it's a bug and not a feature request in disguise.
This doesn't change the original point that such behavior makes it less likely for users to bother with detailed bug reports. Bug reporting in OSS isn't just the developers doing free work for the users to fix their issues, it is also the users doing free work for the developer QA-testing their software.
The thing I dislike the most about the Linux world is how free software/developers are somehow exempt from any kind of criticism because it is "developed by volunteers."
Criticism is fine, as long as it's constructive and not to the tune of "these volunteers are not volunteering to my satisfaction".
I completely agree with you. It's generally bad form to complain about something that is provided to you free of charge but sometimes even then criticism can be warranted. There is a tendency to immediately swat away any kind of criticism of a project or even just a particular developer's behavior with "how dare you complain about free software!!!".
> Try submitting a bug about how menus are displayed 5px from where they are supposed to be in a GTK app rendered on a X11-server that runs on the Windows desktop and see if the GTK developers care.
This one sounds so specific that I suspect you must have a reference to a bug tracker or a mailing list message somewhere. Do you? Having the context of the whole interaction is helpful when forming conclusions.
Without the benefit of such context, I'd suppose that the effort of reproducing the bug (not everyone has a Windows machine handy; the X11 server might be commercial or obscure) is a petty good reason for not giving it more attention.
The devs for the game factorio encourage players to post bugs on the forums. The devs use forums as a issue tracker and respond to bugs with fixes. I have no idea if that makes it more satisfying to report bugs or not, but I always thought it was cool.
I would defibitely file bugs with factorio because of the devs, but never found any. Truly amazing game.
Factorio also has automatic opt-out crash reporter. A lot of people in here are against opt-out, but once they added this years ago, they fixed tons of crashes which were NEVER reported.
The aversion to opt-out exists because it's associated with tech corporations tracking everything in a maliciously intransparent way, using some convoluted opt-out process as an excuse to give the illusion of respect for the user.
If a game just sends info about a crash I couldn't care less.
I disagree and think it should still be opt in. Crash reports tend to include memory dump which can easily include information about the system (environment variables) that the user did not mean to share. It's not unreasonable to pop up a dialog before uploading crash reports which also gives the user an opportunity to optionally add additional information.
In contrast, I stopped submitting bugs there because a forum is a terrible place to find and track bugs. Shame because I knew they'd be fixed by an outfit such as Wube.
factorio needs to be studied in general for the quality of the software, it's performance, and the UI.
The UI has the best productivity-focused design I've ever seen in any GUI application. And its a game. Absolutely incredible.
A forum is better then nothing but a proper bug tracker tends to be less chaotic. Depends on the features of the particular forum software though.
Yes, disappointing handling of the bug reports, discouraging that person from doing bug reports again for anyone.
As a submitter, you can decide to invest in someone's detailed bug report form, including attaching screenshots, etc., maybe taking an hour or more, and derailing the work mental mode you were in.
After that work, what you learn most likely happens next is one of the following:
* Silence.
* "Yes, that's a problem." Then silence.
* 6 months later, automated email saying that this bug is automatically closed, due to inactivity.
* 2 years later, automated email that they've done a new release, so they've decided to throw away all open bug reports. But if you still find the bug in the new version, you can file a new bug report, they graciously offer.
* "We know about that bug, but we aren't going to fix it." For reasons you don't understand. And if there's a cultural mismatch, the tone can come across as hostile or disingenuous, besides.
* "This is a duplicate of bug X." It is not.
* Closes the bug report suspiciously, perhaps for optics or metrics.
* (Silence FAANG Special Edition: A high-profile bug report, on which tens or hundreds of knowledgeable people are adding on, for years, all saying this bug is a huge problem, and many asking in the bug report comments why is nobody from the FAANG even acknowledging this bug report in their own bug system.)
Suggested practice: If you ask others to invest in reporting bugs (by having that bug report form there), then follow through in good faith on the bug reports you receive. (At least on the bug reports that seemed reasonable, and that invested effort in your process.)
I ran into a bug at work where an app would crash and I’d get prompted to submit a report. It would happen several times per day. I often question how many bug reports I should submit for the same issue, and how detailed I need to be with each one, if the information has already been sent. I probably sent at least 40, hoping they’d fix it just so they wouldn’t have to hear from me anymore. Some were professional and helpful, others were mostly empty other than the log they generated, and others were a bit unhinged where I simply vented my frustration over all the crashes. I don’t think it was ever fixed, I just eventually didn’t need that software anymore.
Transparency in the form of a public ticket tracker would solve that.
Gitlab begs to differ.
The number of times I’d google my problem and find a ticket from 6+ years ago with dozens of users participating in the comments, confirming it’s a consistent, common problem, and not a peep from their devs.
It’s like their public issue tracker only exists to insult their users.
Well just look into atlassian issue tracker. It‘s the same for them and sometimes bugs are old enough to drink alcohol.
The sad part is that their cloud services also often don‘t support basic features which their self hosted software offer…
Apple doesn't have this. They're super successful. I hate it! But, clearly that's not an argument most bean counters are going to care about given such successful companies have some of the worst feedback mechanisms.
They are not super successful at fixing bugs.
They are super successful at creating them, though: https://news.ycombinator.com/item?id=38104554
Apple has one of the most public support community[0]. You can get workarounds for most of the bugs, but never from official devs. Even hours old post has dozens of replies[1].
[0]: https://discussions.apple.com/welcome [1]: https://discussions.apple.com/community/macos/sequoia
Same experience. Not even a tech person but I have reported obvious typos a few times. I think I got a thank you letter once and it was two months after I reported, that’s it.
This is like how I stopped reporting stolen bicycles.
The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports, or the "my neighbour is a spy for the government and I have proof" reports (real types of reports for a browser company, for example, which surely exist for other places users think that "is" the internet like Facebook).
I agree that reporting bugs can be hard, but the amount of spam that follows an effective open form, of craziness to uselessness, outweighs the useful bug reports.
Having two types of reports: one which is a simple screenshot taker with the ability to draw a circle over what is wrong, and one which is a more detailed report, would be useful.
Some LLM that filters out what is a useless report be a useful report would be good, too.
With all due respect, That is the price you pay for your users doing _free_ software testing for you! We are on the “listen to your users” mecca and you’re complaining that listening to your users is hard and you wish a machine could help you with it.
>for your users doing _free_ software testing for you!
In comparison to _paid_ software testing, which doesn't change the point at all: if they were paid to find bugs, they wouldn't be paid for useless and unactionable reports.
>you’re complaining that listening to your users is hard
Sometimes - and I'd wager most of the time - they are, yes, unless your product solely attracts technically competent and advanced users that can attempt to understand/reason about what is causing the issue.
> you’re complaining that listening to your users is hard and you wish a machine could help you with it.
That's entirely the wrong take, IMO.
Listening to users is easy, but the users often don't say anything when they speak. Those non-reports are basically spam that should be automatically thrown away.
When a mozilla application crashed it'll ask you to leave a comment to try and help resolve the issue when it prompts to send crash info, and you used to be able to see all those comments on https://crash-stats.mozilla.org (it seems to be behind login or restricted access now). There was a lot of vitriol and unhelpful comments that any developer would need to wade through to get to anything to give them a lead
It also leave a coredump, they can remove repeated entries and then filter by good comments
I have a tiny bit of sympathy for this, I have received a bug report that said “Your software doesn’t work”.
I’d always reply though, usually with something equally terse.
Most recently, a github user opened a issue on one of my projects and asked "Why should I use this instead of Y".
As a developer sharing my code online, I don't even know where to begin answering that.
This is typical non-tech spam.
No this is a valid request.
If a user wants to use a piece of software to do A and several different pieces of code do that - why should they choose yours.
What is your selling point.
Especially if they have been using the other product why should they switch to yours?
If I'm writing FOSS and someone asked me that, I'd just reply with ¯\_(ツ)_/¯
I'm not making money from it, so trying to convince some random individual to use it is a waste of my time. Sure, I'll describe the features in the README and possibly include comparisons to other software, but I won't go out of my way to convince a specific rando just because they asked.
I think a lot of people here seem to totally fail to understand the user's perspective. Reporting on bugs is hard, because adding actual, helpful context to a bug is actual (free) labour. Yes, filtering out useless reports is hard for you, but that's the price you are gonna have to pay for having people do free labour (you get some unhelpful reports). You want to increase signal-to-noise ratio by focusing on decreasing the noise, whereas you should actually focus on increasing the signal.
Making simple, useless bug reports is easy and it will always be the easiest. Also the "my neighbour spies for the government" types will anyway always be the most motivated ones. There is no way to make it hard for "bad" reports without making it harder also for useful reports (barring some obvious cases of bots, ip filters etc, which are not what is discussed here and are a general problem not just for bug feedback). By trying to reduce the noise, you also reduce the signal thus get a worse SNR.
The specific tool is smart in trying to increase the signal. If you make it easier for users to add some useful context, MAYBE you get more users actually giving you sth useful, maybe even users who otherwise would not bother to add anything more useful than "it does not work".
I use software that recently made much simpler to make bug reports and add context, and they say they actually receive much better bug reports after. And most importantly, the users actually see that the bugs get fixed, which motivate them to make more, and more detailed, bug reports. Imo getting bugs fixed (and maybe even recognise the users' contribution in reporting them) is the best way to get good bug reports. Honestly, from my user's perspective having my feedback taken seriously is the best motivation for me to continue submitting reports. Because, honestly, sometimes bugs come up in complex situations that may be tricky to understand/reproduce, and it is hard to understand what context is relevant. I am not usually motivated as a user to spend like 20 minutes figuring out exactly how to reproduce a bug, but if I see that the company/engineers actually care and try to make it easy to me to report to them, I may actually do it.
Yes you are gonna have bad interactions also (and remember people have their own jobs/lives/not enough time to always engage with you the way you may want them to in providing feedback), but the point is to increase the good/useful interactions (compared to them), not decrease interactions in general. Unless you do not care much about bug reports anyway, that's also fine.
> The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports
This so much.
I can't tell you how often I've seen someone trying to get tech support on something say "When I load the program, I get an error" but don't even say what the error says. I understand that most people have never worked a QA job and so don't know how to write a good bug report, but certainly I would expect someone to copy/paste the error message.
> I would expect someone to copy/paste the error message.
If you're talking about non-technical users, they (a) don't even think of copying the error message, (b) don't know how to copy the error message, and (if the error message isn't directly copyable) (c) have no idea how to do a screenshot.
> "When I load the program, I get an error"
You're lucky if they even say that. Many public bug trackers I've seen are just filled with spam, entitlement and anger, demands/threats, or incoherent fever dreams of very unwell people. Forget about getting logs or reproduction steps. When you open bug tracking up to the public, you're lucky if what you get back is even remotely serious.
Relevant xkcd https://xkcd.com/2501
It's weird seeing people without computer familiarity using one, it feels like they are blind, they click in a button with a label and a icon, and when you ask todo it again they can't find it(even when you literally tell them the button name), it feels like their vision FOV is limited to a few centimeters, like those horror games flashlight lol, it's my own experience, but yeah, they aren't going to remember the error, or don't even read it, imagine print screen it before clicking "ok"
What's worse is how much the modern world and software quality has trained them to just be so helpless.
My mom has been using Windows computers since before I was born. She would spend all sorts of time working on the computer, creating tests for her classes, researching my sister's illness on the pre-2000s internet (with great success even!), had no problem adopting software over the years as things upgraded and changed, had no problems pivoting to using a Macbook at work, had extremely few problems adapting to remote learning, to the point of asking me for advice using OBS to improve her ability to run a virtual classroom (for things like different "scenes" and control over her output video). She broadly understands the concept of "files" and directories and how to move them and transfer them and manage them well.
But at some point, she forgot how the "Start" menu worked! You put her at a Windows desktop and she doesn't know how to start the program she needs to use! Do you know how much goddamned money Microsoft spent ingraining the start button in people's heads in the 90s?
But it's just gone. Because modern web based stuff follows no patterns. It makes no sense. Shit just happens sometimes, with no feedback, with no warning, and sometimes breaks while only leaving a damn error message in the javascript console, and the behavior changes from one day to the next. The only way people who aren't experts can hope to navigate this hellhole is to learn EXACT workflows and never change them and never think of changing them and never attempt to do anything novel in case it breaks everything without warning and don't pay heed to any dialogs because they don't contain useful info anyway.
Like, what did we expect to happen when we punished people for trying to build mental models of this stuff? You cannot build simple mental models of webapps. Companies don't want you to, because then you might not be as bamboozled and you might be less susceptible to advertising.
[On a thread about how people don't read]
Yes, and some of the details really need to be emphasized, because I'm sure that a good chunk of people assume this means "people don't read more than they need to / people have a lack of inquisitiveness and general competence matching their lack of interest in reading for personal fulfillment" or whatever.
No, no, this is literal and (almost) not exaggerated. They _don't read_. Anything. _Ever_.
The almost-not-exaggeration is in the "ever", if anything, because some of these people can eventually be compelled, with much sighing and gnashing of teeth, to actually read something.
But as a matter of course, they don't read. And that's not just "don't read what they don't need to." It's more like, you know how your eyes happen across some text and you just read it inadvertently? And your daily life is full of moments where these glances at random words give you little reminders or flashes of insight or just fuel for the train of thought? Haha, that's a good one. I didn't even do that on purpose. Anyway, they don't do any of that shit, they literally have to start reading on purpose and the rest of the time, as far as I can tell, they are actually not processing any of it at all. They navigate the computer/phone by rote or by visual cue based on color/position of UI elements. When they can't figure out where to go using that method and you suggest that they actually, like, read the shit on the fucking web page they're trying to navigate, they ...
... start at the top left corner ...
... and crawl the page elements linearly ...
... and when they arrive at the correct one ...
... there's a pretty good chance that they won't actually recognize it as such, because for some reason they simply can't contextualize any of the shit they're reading!
These are people who have jobs and social lives, are not wards of the state, and can carry on a coherent, reasonable, and engaging conversation with you.
(No shade thrown to visual thinkers though -- there may be some overlap, but I don't run into these people as often as I run into visual thinkers, so I think I'm talking about something else)
Whenever I saw statistics about literacy rates in the USA being startlingly low, I never believed it.
But then I remember many interactions I've had with people while working with the public, and...yeah I believe it.
You're right. People simply don't read. They don't even notice there are words somewhere in their vision. I used to work at a water ride at a theme park, and people would ask if they'll get wet on it, and there would literally be a sign right next to me that said "You will get wet on this ride, you may get soaked".
And then, occasionally, I'd have someone read it out loud, slowly, "you...will...get...wet..." and then be like "I don't understand, will I get wet on this ride?" and they're not even joking. They can turn the letters into sounds and words, but can't comprehend the result, yet if I just repeated exactly what the sign says, they understand it fine.
Now I wonder how many people that struggled with "word problems" in math simply weren't literate to begin with.
On the LLM idea, if you could group reports by issue (by parsing the user provided input and whatever context you save from the page screenshot into some embedding) and then only escalate things when several different IPs have reported a similar thing within X amount of time, I think you could handle two birds with one stone. Limits how annoying spammers can be, and also makes the good reports easier to understand since a few bug reports combined should make a better whole.
I however wouldn't shorten/transform reports with an LLM, or make spammy reports inaccessible. Just doing the semantic grouping for escalation. It's true you're getting free work from your users, and the human factor is pretty important here, even if an LLM might sometimes misinterpret it.
> "page doesn't work" with no further explanation reports
It cuts both ways. Guess what's one of the most popular format for apps and webpages to report failures to the user?
"Oops. Something went wrong."
Not exactly overflowing with useful information, either.
Sure, the system is probably logging the fault internally, and is always collecting metrics that help with contextualization later. But the system and its owner aren't usually the ones most affected by any given bug - it's the user who is. The user who's now worrying whether it means they're about to lose the time and work they put in the current session, or whether the app just ate their money (failures half-way through payment processes are the cutest, aren't they?). They don't know - maybe the "Oops!" was just benign, or irrelevant. Then again, maybe they've already lost it all 10 minutes ago - back when the previous "Oops!" briefly flashed to gently inform them that the service's back-end tripped over itself and died - but they won't discover that until later, at which point they'll be neither able nor willing to make a proper bug report.
Point being, if one sees their users as being 5 years old (but with parents' credit card in hands), one shouldn't be surprised to only ever get a kindergarten-level error reports like the ones you mentioned[0].
This is not just me complaining on a tangential issue - I believe showing specific and accurate error messages improves the ratio of useful error reports. It's not a full solution, but it's a step in the right direction. Treating them as partners, instead of a bunch of brats you have to put up with until they complete the payment, makes them more willing to reciprocate; giving users means to contextualize their experience allows some of them[1] to understand what's going on, and gives them something useful to put in the report too.
That, or I guess nowadays you can also keep the "Oops."-es, double-down on telemetry, and feed the metrics to a SOTA LLM to identify and interpret failures for your engineering/operations team, which we all know has neither time nor patience to do it.
--
[0] - "Page doesn't work" is the adult version of a kid suddenly starting to cry for unclear and possibly non-specific reason.
[1] - Obviously, not all, or even most. Software is complex, most users still behave as if half-drunk and unable to read, etc. Still, even 5 year olds can comprehend basic words and identify patterns. Figuring out that "could not connect to payment gateway" is serious, that "failed to write [blah blah tech terms]" that happens at random is probably not, etc. is within the cognitive reach of most users.
>Something happened! :(
Yes, I love it. How helpful! I'm so lucky to have such a meaningful error message to Google. Now I only have to blindly try a list of 50 possible fixes before I discover that I couldn't save a replay on my XBox One because the disk was full.
Naturally, the stock counterpoint is that this happened because users thought real error messages were too scawy! :(
Counter-counterpoint: Oh well
Most companies don’t have a user accessible way to file bugs. Often, you have to call support, speak to a muppet, then convince them that your issue is real and they’ll file it. Trust me, I find bugs in products all the time and I actually try to file bug reports, but it’s rare that I can.
Some of this is because one of the worst bug-related metrics is “customer found bugs.” This means that your developers missed it during unit testing and your test team missed it during system and final testing. Nobody actually wants customers to be able to file bug reports because they make the team look bad.
Goodhart's Law in effect.
> If you've ever had a user say “something’s broken” and then ghost you forever, you probably get where I’m coming from.
As a consumer who reports bugs, I’d actually say the opposite problem is just as common — when the company ghosts you after you’ve taken the time to report an issue.
I’ve lost count of how many times I’ve used the official channels — bug trackers, support forums, contact forms — only to hear nothing back. No acknowledgement, no follow-up, no notification when it’s fixed. Honestly, I don’t think I’ve ever had a company let me know that a bug I reported was resolved.
Reporting a bug to most companies feels like sending a wishlist to Santa. That’s why many people don’t bother. They assume it’s a waste of time — and most of the time, they’re right.
Personally, if a company fails to engage over a bug report, I don’t waste my time reporting anything else. In many cases, I just move to the competition. I’m sure I’m not alone.
If a user goes to the time of helping you fix your software, the least you can do is spend some time on them.
Having run engineering teams for some reasonably popular open source products, my experience is that community reported issues can easily out-pace engineering capacity.
For every user who reports a clear, reproducible defect, there 10 others who report non-reproducible issues, who conflate features with bugs, who ghost, who use issues for support or questions, who are just angry about something and think you're an idiot, who report (since fixed) defects against old versions, or who report duplicates to existing issues. It's a very noisy channel.
It can lead to a crappy outcome for both the reporter who earnestly tried to help and for the developer who wishes they had the time to carefully address every reported issue but just don't.
Sometimes, all that's feasible is making time to triage/acknowledge each issue in a reasonable timeframe and to be forthright about its prioritization.
As an aside, I find your opinion that "if I give you my time in the form of a bug report, the least you can do is give me your time" to be common. We rarely have the right to demand another person's attention, though. Especially with respect to non-commercial open source hobbyist maintainers.
> Having run engineering teams for some reasonably popular open source products, my experience is that community reported issues can easily out-pace engineering capacity.
The solution to that is to have an additional triaging capacity. That can come from the community if you empower them with e.g. a public bug tracker.
If you truly do not have enough capacity to even fix the valid bugs then you have much bigger problems and no change to the bug reporting mechanisms will help you.
> As an aside, I find your opinion that "if I give you my time in the form of a bug report, the least you can do is give me your time" to be common. We rarely have the right to demand another person's attention, though. Especially with respect to non-commercial open source hobbyist maintainers.
This discussion is in the context of a post about a getting users to report bugs. Users might not be entitled to a response to their bug reports just because they spent their time but you sure as hell are not entitled to users telling you about issues encountered with your software before they inevitably get fed up and move to an alternative. The point is that if users feel they are wasting their time they won't bother - and the first to go will be the high-effort bug reports with useful information.
And this isn't really different for open source hobby projects - as long as you care about improving your software you'd do well to not make users who are willing to make good bug reports feel unwelcome.
Yes. I have built effective programs that empower community triage and committers.
My point is that a minority of issues to publicly available issue trackers are high quality (or even actionable - beyond triage), despite everyone thinking they are only posting high quality issues.
> you sure as hell are not entitled to users telling you about issues encountered with your software before they inevitably get fed up and move to an alternative
We totally agree on this.
The only exception I’ve found to this in recent years is JetBrains. Every bug I’ve logged with them has been fixed.
Reporting bugs is work, and is a two-way street: if submission is a black hole (possibly with some scripted replies from someone uninvolved in fixing bugs), then bugs will not be reported.
The response is usually the problem.
If I file a bug I get either:
1) nothing
2) a reasonable response that may or may not include resolution
3) a shared debugging journey that takes three hours of my life
Number 3 devs mean well and have admirable commitment…but I’d rather not sign up for an epic trek to throw a ring into mountain doom. I just want to point out an issue and provide some basic info.
So these days the only thing I do for the most part is send crash logs.
A couple of years ago I played PUBG which crashed occasionally. I rarely submitted bugs, even if it was as simple as pressing a button in the crash reporter. This is because sending the bug report took a while and blocked you from restarting and rejoining the ongoing game. This applies mostly to multiplayer games but if your app has a crash reporter, give the user a chance to restart the app and report the bug later.
The opposite would be something like the bug reporting system in Second Life by Linden Labs (an online world where you can be with a virtual avatar, doing stuff) (at least way back, i dunno if they still have that open).
They had a public facing jira open, where people could file bugs and what not about the viewer (the client) and the world (the server).
You didn't need some special account or something like that, just your normal Second Life account was enough to get access to that one.
Drawback was, you were able to see what happens when filing bugs is easy. Of course, many people used it to file real bugs but also complained about stuff not working like they expected (or how it should work according to them, which brought other people up against them and so on...in the end you were able to read the latest drama here and there, right in the jira entries).
Although, to be honest, i thought it was an awesome idea, but you when you open up an easy way for people to report bugs, you need an easy way to explain what bugs are and what not. :)
Just this week I was working on something similar but specifically for users who have disabilities, so they can more easily report issues to site owners. I also combined general annotation capability so other users (of my browser extension) can read their comments. And also compatibility with Hypothesis (https://github.com/hypothesis, https://hypothes.is), also using the W3C Web Annotation spec. I hadn't thought of the drag-and-drop bug metaphor; I like it. I had also considered recording mouse and keystroke events up until the time that the bug is marked, and then bundling those events (sanitized) with the bug report for more precise repro steps, but of course that's a bigger ask for the opt-in.
As a user the best thing you can do to make me report bugs is to show that you are actually going to fix reported bugs. Taking my time to gather information that will effectively end up in /dev/null is the opposite of fun.
Also important is to let me make sure I don't waste time reporting something that is already a known issue.
The best way to do this is to have a public bug tracker.
Given these preconditions acceptable effort only depends on how invested I am in the product.
> screenshots, browser info, even console logs if they hit an error.
Possibly disclosing sensitive information (which the user may not realize).
In 2022 and 2023, I made a push to find and fix bugs in OpenZFS using static analysis tools. I found many obscure bugs. One was a theoretical issue that should have affected big endian systems and been an annoyance for users, but there were no bug reports saying anyone had been affected. After I opened a PR with a fix, people told me that they had been affected, but did not think it was worthwhile to file a bug report. This surprised me. This is the PR:
https://github.com/openzfs/zfs/pull/13968
For many corporations, there are probably perverse incentives against making it easy to report bugs.KPI of reported bugs as an indicator of software quality, for example.
It's not just a problem in the corporate context. Open source projects usually make it a pain in the ass to submit bug reports too, in a clear effort to gatekeep the process to experienced developers. Simply because developers prefer to only deal with other developers and don't want to hear complaints about their software from the unwashed masses.
Free software developers already doing work for free. You are demanding more free work?
I can’t imagine I’d keep up a hobby of doing customer service type activities very long.
Certainly seems like there must be some KPI against fixing the bugs. You can look to any big tech software and find oodles of long standing bugs which never receive attention.
Fixing bugs don't create features, that upset execs
I really like how some indie games have put in a widget for feedback. Press F11 or something, click an emoji face, optionally add a description, and click send. The game takes care of sending a screenshot, game state etc. (It tells you it's doing this in the interface)
Totally get this. I once spent days trying to get users to submit decent bug reports through a fancy form and got almost nothing useful. The moment we switched to a simple “click here to report” button with an optional note field, the volume and quality went way up. Simpler is better, especially when the user is already frustrated.
Any involvement in reporting / fixing bugs is development. Why do app developers think their customers need to be or want to be developers?
What other industry relies on its customers as implicit developers?
Making bug reporting easier means an intentional push to foist more of Development's work upon customers and a bias towards more bugs.
BUG OR FEATURE?
If you can't tell, then we can understand why Knuth call it "the art" of computer programming, as in the artist's uncertainty of creation as compared to the engineer's confidence.
The fact that half the SW industry prefers to avoid a distinction between bugs and features— as in bugs that don't get reported are regarded as features— shows the profligate laziness and opportunism of so called Software Engineering.
AI is a stunning example of a global industry built by computer technologists who don't care about understanding their own work, and lack the creative and social spark to conduct themselves as artists.
Just listen G. Hinton babble philosophically for 10 minutes and you will grasp the magnitude of incompetence at work.
I think reporting problems is just part of being a good citizen that participates in a shared culture. If I visit a park or shop and something is broken, it's worth putting in a bit of effort to report it. If everyone chips in a little bit of effort it makes the overall experience of everyone much better. Are you the type of person to also not return the shopping cart to the corral?
The number of hardware and software combinations are impossibly large, so you're unlikely to be handling everything perfectly if the application is doing anything complicated.
> What other industry relies on its customers as implicit developers?
I would say most of them. To list a few:
- restaurants (almost all of them will send you feedback surveys these days, they also rely on you to tell them if they, for example, cooked your steak to the wrong temp)
- property maintenance (again, feedback surveys)
- auto mechanics (if the thing they fixed is still broken, a good mechanic wants to know)
- doctors (they rely heavily on YOU to tell you what wrong with your body)
- democratic political systems (when working correctly)
- road infrastructure (the city won't fix potholes nobody is reporting, and they won't do anything about badly tuned traffic lights nobody complains about)
- vaccines and medicine (the testing phase may not uncover every possible single side effect, they need recipients/users to report those if they happen)
(Please nobody come back with cynical takes on how these aren't helpful in their specific case/location, that's clearly not the point)
none of these are bugs, they are complaints about specific date/time/incident.
restaurants
undercooked steak is not a bug unless every single steak on every single day is undercooked
property maintenance
same thing (and weird example)
auto mechanics
also not a bug, bad part, mechanic who didn’t get laid the nite before… not bugs…
doctors
not sure how to even respond to this… :)
democratic political systems
would be nice :)
road infrastructure
wear and tear :)
I think it's a given that I'm not using perfect metaphors, dissecting them is ignoring the point.
Users operate with different configurations, hardware, and needs. It is literally impossible to release bug free software. Every developer should try their best, obviously, but NOT requesting that bugs be reported is pure hubris on anyone's part
The unfortunate situation is that bugs in modern software just seem to… show up, as if their appearance is an ongoing maintainence issue rather than the outcome of something somebody on the development team did.
But, anyone who took the time to write bug-free code went out of business decades ago.
> Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects.
Maybe people could combine this reporting solution with a bug capture solution I built a few weeks ago? It's a web-based screen recorder which allows a user to gather together several different areas of the screen into one place, add a talking head of themselves and demonstrate/explain the problem they've encountered. The resulting video could be added to the bug report. I built the tool because showing the problem is always better than trying to explain it in words.
Tool: https://kaliedarik.github.io/sc-screen-recorder/ GitHub repo (it can be forked, self-hosted, etc): https://github.com/KaliedaRik/sc-screen-recorder
When I encounter a bug, I will almost never report it either, I’ll hope that someone else will or the developer will notice themselves while using their product.
Reporting a bug is work. If it is certain that the bug will be fixed upon reporting this work may be worth doing for selfish (or non selfish) reasons, but I almost never have confidence that it is.
Sounds like a great idea.
I have found that users don't give feedback, positive or negative, until they encounter some extreme (usually negative).
I have found the best way to encourage feedback, is to make it dirt simple. Just a text entry field, with some way to respond, so you can follow up.
Most of the work needs to be on my end.
I stopped reporting bugs when projects started to deploy bots that close "stale" bugs. No, someone ignoring my issue for 3 months does not imply issue went away.
I was cool when bugs waited for proper prioritization 6 months later. Ok, it took time, but someone is busy. When they are getting closed automatically, there is no reason to bother.
I don't know if this is the case now, but about a decade ago, in order to report a Bug to Microsoft you had to create a Premier Support ticket, which cost $1000+, but free if it's a Bug. So basically, if what you report is not a Bug, determined by them, it's treated like a Tech Support ticket and no longer free. I recall discussing this with a representative and let them know that I'm basically doing them a favor by reporting the bug -- why would I want to take the chance to possibly have to pay for it if they happen to determine "it's not a bug -- it's a feature". I got the standard corporate-speak answer which I just waved off as ridiculous: "Look, we will absolutely not charge you if it's determined to be a bug"... :|
I've since have seen Microsoft use User Voice and the products (at least Visual Studio) has a great way to give feedback to the team, something I've used multiple times, including for feature requests. And of course, for their Open Source products, they have Github Issues, which is awesome.
“Stupidly easy” is bad copy imo. I honestly did not want to scroll through the front page after seeing it. In a sentence it does not have nice flow and from a business perspective it feels immature. I would tighten up that copy a lot but that is just my opinion. Also, might be in the minority but I avoid any products that put ProductHunt flags on the page, especially prominently at the top.
I had a lot of success adding links and buttons to report bugs on error pages and messages. Doing that while whatever abnormal state led to the message is still hot allowed me to gather a lot of information about the state of the application to be attached to any bug report. Initially I used the Macintosh bomb icon for it, but some users found that too cryptic compared to a text message.
Bugdrop won't work for most users, since they don't real tooltips.
1. I load https://bugdrop.app/
2. The site days 'try bugdrop' and points to the left bottom corner.
3. I click the bug. Nothing happens.
On further inspection, there is sometimes a tooltip that tells me clicking won't work and I need to drag the bug over the part of the UI that failed, but I didn't read that when I first used it and I won't use it a second time.
Thank you, Nailer. I'll definitely be doing some tweaking around that part.
Thanks! Pardon if my feedback sounded direct, I wanted it to be impactful. I’m imagining somebody will click on the bug, you will show them very visibly that they need to drag the bug to where they need. When they drop it, they can fill in the form or move it somewhere else.
I'll report bugs, give details — via multiple cumbersome steps, iff I can clearly track the status, follow up. Otherwise, even a one-click “send report”’popup isn't worth my effort. This is why I no longer bother reporting anything to Apple. Same crashes/errors keep on for years. I’m convinced those reports go to /fruit/null.
I won't report bugs in paid software/services because it's not my job, I'm not paid for it, I'm user of the service, not free workforce so they can reduce amount of QA staff or skip it completely. Give me a discount and then maybe, just maybe I'll think twice about reporting something. Bugs renders your soft unusable? Fine, there is plenty of competition out there who will do it right.
A clickable link with a form (partially pre-filled) and a big banner that says if the bug is verified I get 10-25% off something AND a followup email (reiterating the offer) + tracking link, would motivate most people I know.
> because it's not my job
I've worked with people who uttered this phrase many times. You really should put this on your CV because it's an incredibly helpful indicator of character trait.
I just reported a bug on Kobo app and got a thanks and a discount on my next purchase.
I also just got a first response about a bug I reported 5 months ago,
It really depends on the author
So instead of getting a fix, you'll choose to be angry.
It is an approach, for sure.
I tell my customers that they should spend 1hr per month “improving the vendor”.
See, if you rely on a vendor, then you need them to survive. It’s a parasite-host relationship. You need to tell them what you need, and oftentimes they will bend the roadmap in favour of the most demanded features. Alternatives:
- They choose their most amusing feature,
- They choose the most lucrative feature among the new possible markets while ignoring all bugs, which is the most rational way to address bugs unfortunately,
- You don’t tell them, they don’t improve, they die / they triple the price of the product by lack of audience, and you have to migrate your data to another product.
Nice, I hope you are spending 1h per month for each customer as well advising them how the can get the most out of your service and/or improve their integration - otherwise it would seem like you are expecting unpaid work from your customers, which is ridiculous.
I hired a house cleaner. I didn't tell them what to do because figuring that out is their job. They didn't do the things I wanted and they even missed some spots on what they did do. I didn't tell them about that either. It's they're job. So I fired them and switched to another. Repeat. Maybe eventually one of them will figure it out.
You hired a house cleaner, you told him everything he needs to know, he did a good job. Next time unfortunately he arrives with broken vacuum cleaner, he has another one, smaller, less powerful takes him longer to do the job but it's still done, not spotless but it's fine, he is a nice guy, has good attitude. Another time and he arrives with faulty steam cleaner, again , work is done but takes longer, not ideal outcome. This is happening again and again, he even asks you sometimes to wiggle the cord, push some buttons and try to troubleshot, you know, improving the vendor and stuff.
So you:
A) only pay for perfection and
B) experience zero friction or cost in moving services?
I think trying to argue with the sentiment, misses the point entirely. I think we can all agree, bug reporting could use a renaissance.
Maybe adding a clickable/highlighted actual url in the post to make it more stupidly easy to go to your website, if not on the title itself (not sure if you can add that now) could also be a good idea. For stupid people like me that spent more than 10 seconds after reading it trying to figure out where I should click.
Because it is an extremely futile exercise.
I have a bug in my Honor (200 pro) phone were after some time, whatsapp's notifications with no sounds are changed by the SO automatically to Gentle Notification (no popup, only number on icon) I want to have a popup, but without sound. I might have reported several times, well, they have not done anything about it.
I also reported something to Lutris just to be told, not our problem wont fix. which is the same feeling of, why have I bother doing this.
And after a few of those, if you have a bug, you moved on. In this case I regret going with Honor instead of Samsung, and it would be likely the last Honor phone I got and I do not recommend to anybody. And with Lutris, I would rather use windows and be able to see my screen instead of a black box when logging into epic.
If you don't fix the bug, the user will stop reporting, and will find a workaround.
I think it's cool you built and shared it - grats on shipping.
But you (or your users) are about to learn a few truths about bugs and users :)
Foremost: unless your users pay for the product, there's a downside to easy bug reports - the vast majority will be useless, no matter how easy it is. Granted, that's true for paid products too, but at least you can bake the cost for dealing with that into the price of goods.
It's absolutely great while you're building traction. Even the most inane post has usually a kernel of truth. It's becoming a problem as you are clear on where you're heading, and the cost of dealing with them outpaces their value.
At that point, you either start stochastic sampling (annoying your users who write well thought-out reports, and who are your multipliers), or you spend a fortune to slog through everything. That's when you start writing the "feedback suite" backend :)
For me the most fatal part of the big report loop is where you report a bug, and get radio silence, or a curt dismissal, and the bug lingers on.
Telegram for MacOS has a bug where it will occasionally crash when you try to delete something. I reported it nearly 2 years ago. It's yet to be fixed
On the flip side, I got some of Fireboard's pulse probes last year, and had an issue where they wouldn't connect to my Yoder smoker. Quick ticket and some easy debugging steps I was able to do more or less asynchronously, and a cause and fix was found: the Bluetooth stack on the smoker would crash after a while, so unplugging the smoker when it wasn't in use was an easy fix. The bug still remains in the firmware, but there is a solution that works for me, and so I'm happy with a functional product, while I wait for the firmware update
Not potentially a customer because I have very few users that I can track if one of them have issues. So take my suggestions a bit lightly
1. I'd rather have/use a npm package then your minified/package script. You are not Google, so I am going to need some trust there and that happens by making this an open source package.
2. If I am going to implement this on my site, I'd not use that little bug. I'd rather have this custom design/integrated with the rest of my app. So provide API/functions/Hooks to use your library.
3. I'd never consider a one time payment (lifetime subscription) SaaS. That screams: I am going to take your money and disappear in a few months. Also, any product that doesn't have clear bandwidth quotas is probably missing in disclosure.
I strongly recommend going a lot less heavy on the LLM generated writing on HN, it reads far less genuine than when people here right stuff themselves.
Just in case you think it's the em-dashes that do it, it is isn't; it was clear by the end of the 2nd paragraph.
This looks an awful lot like all the "contact us" forms that are mostly broken and give you no feedback as to whether the message got through or not. At least it's easy but you can bet half the sites that use it won't even be receiving the reports, let alone acting on them.
In my desktop app, I ask users to email me in a global exception handler. My thinking is that they'll recognize that I don't want to be inundated with reports for the same bug over and over so they're probably the first to find it and it's worth reporting. And I do fix them all otherwise I would be getting spammed by the same reports over and over again.
If you submit a really detailed bug report, such as one where the problem was reproduced under a debugger, it becomes a "the reason you suck" speech. This really upsets some dev teams. The usual responses of the "turn it off and on again" and "reinstall" don't make the complaint go away.
There are two bugs in Firefox I'd like to report, but it's futile. One is that, launched on Ubuntu, Firestorm does disk I/O for about three minutes on launch. During that period it can't load complex pages, although it loads ones without Javascript fine. The other, again on Ubuntu, is that it freezes when large text boxes are being filled in. This only happens on some sites.
I feel like on windows there's similar issue - after crash (force close) Firefox will load UI fast, but spend several minutes to not show black screen instead of websites in my session
I remember finding 3 year old reddit post about this, and I have no idea whether the bug got into normal reporting place (where even is it?)
I love the UI concept. Being able to point at a broken thing rather than try to uniquely describe the position/state/path to a broken thing is smart!
Hooooever, "bug" could be a bit ambiguous to a lot of people. Looks like in a real deployment, you have a little tooltip that says "Spotted a bug? Drag me there!". That makes sense to developers and the like... but those are also the sorts of people most likely to write a good bug report anyway. The people most unlikely to write a bug report are the sorts of people who will read "spotted a bug" as "there is an insect... game?... on this site?".
"Issue" or "Problem" would be better, but keep the bug graphic! It's cute. :)
When I took a look quickly, it also shows the "Spotted a bug? Drag me there!" every time the page loads - which could quickly get overwhelming, and make the user wonder why the developer is so certain that they will run into a bug. (Why do developers not make "report a bug" obvious? Because just seeing it implies there are enough bugs that a link is necessary.)
I also have no idea how well this works on mobile - and seeing that the Pro plan doesn't remove attribution seems like a mistake.
I agree - the attribution needs to be removed for paying customers, or at least for me to want to pay for it to use with a client.
The phrasing should be customizable. Even better if the bug is an SVG and I can paste in my own SVG for the bug icon.
I was worried about how it worked on mobile, and unfortunately on my iPhone I could not find a way to drop the bug where I wanted. It did show a popup eventually but it covers a lot of the page given it doesn't work as expected.
Just sharing thoughts/observations; I really like the concept as well.
Whitelist options are coming up :) You will be able to customize the tooltip (or remove it), change the Bugdrop branding to your own and more.
I'm aware of the issue in mobile devices too, will push an update later tonight to fix it.
Hey graypegg, you're right about this. I'm thinking about changing the wording of the popup to something like “Something’s not working” or “Spot a problem?”
Cute things that programing managers say: "Problems? We don't have any. In fact, I haven't seen a bug report in more than six months!"
Really excited to try this.
1) I'm surprised to not see the bugdrop feature in the admin section, which means I currently have to report the bug here :-)
2) I was also surprised that it didn't seem to need to confirm my email, seems standard these days.
Otherwise, stoked to try this. I already reported a "bug" on your front page and it went very smoothly.
3) Didn't receive an email receipt confirming that the bug was reported after I had entered my email, not sure if that's planned or not.
Thanks!
This is a huge problem in Apple iOS land where the only way to leave feedback and tons of apps is to leave a review on the app store and then watch Apple delete it immediately
I've left plenty of complaints on App Store reviews and have never seen a review of mine taken down. Did you break some sort of rule in your review?
I spent a lot of time working in the user research space and the disconnect between what users told me and what they did was so huge that I just built an AI that watches user sessions and figures out bugs and friction. Works well for like 90% of cases
FYI, there’s a bug with the bug, it doesn’t move on mobile
Congrats on shipping!
Here's some quick feedback -- hope it's useful:
1. Is the little bug icon sufficiently visible? I'm not sure...
2. Do visitors automatically know what to do with the bug? You have a tooltip, but do all visitors know what "Spotted a bug?" means?
3. [more of a suggestion; perhaps it does this already] Would be great if the bug position pulled in a CSS class or the content surrounding the "dropped" bug -- to give more context to the site owner.
1) The site owner can fully customize the widget, including adjusting the size of the bug icon.
2) I'm considering updating the popup text to something more approachable, like "Something’s not working?" or "Spot a problem?"
3) Currently, it doesn't send class names—but that's a great suggestion. Thank you!
The same applies for translation systems.
I translate a bunch of open-source software, if the translation is on weblate, transifex or crowdin.
I never going to translate .po files directly. It's just not worth it.
The first job I had as a software engineer was at a trucking company that had a desktop Swing application. If an exception happened, the user would get a pop-up with buttons to email support the stack trace or cancel. The email went to all the IT staff and someone would usually reply within an hour, often with a fix.
The engineering work was atrocious looking back. I probably fixed 50 random NullPointerExceptions in my 3 years there this way. But, it was one of the most productive places I've worked at because everything was done simple and there were no barriers between users and developers.
Your product is similar to one I own. I checked out your website. It’s good.
Unsolicited advice: you gotta charge more for this product. A lot more.
We charge up to $250/month or $3000/year. Some customers (companies you’ve most likely heard of) pay that, yearly in advance and have done for several years.
Working at google taught me to not bother. An android bug I filed the month that I joined was closed a part of "bug bankruptcy" seven years later, having never been triaged. Why bother? When I was quitting - a year after that, the actual bug still existed.
Yes! Similarly for text books, which are riddled with errors, generally speaking. They should have have an email address for reader-submitted errata printed in large friendly letters on the inside front cover.
Testing bugs is your full time job. Why should I spend my time doing it for, at best, free, but more likely pay to do so? And even then, the bug is almost always closed without fixing anyway.
I love this. Especially the sane pricing.
Only thing I would add is after submit it should allow you to enter an email address or something so that (a) the user can get updates on the progress of fixes; and (b) be contacted if the dev needs more info.
Thank you, Charles. Yes, this is already on my to-do list and should be available in the next couple of days.
Not a fan of made-up testimonials, but otherwise it looks nice. How do you prevent spam?
Nature takes the path of least resistance. In my experience, especially people. Make it easy people will use it, make it difficult and they won't.
It's the reason apple became apple, even though I don't think the iPhone is intuitive today.
> Make it easy people will use it, make it difficult and they won't.
It doesn't have to be difficult. It just has to be not easy.
The most I have tried with reporting bugs in a mobile app is going to settings and seeing if there’s a bug report button or something like that. Not worth the effort considering the low probability of it being even looked at.
Same with engineers working on the code. Track issues in GitHub? They'll write bug reports. Track issues over in Jira, they no longer care enough.
Or just use post hog or clarify to have sessions and check them? That helped me to find bugs without reporting.
The other method I used is to have audit logs, identify when there are errors in certain steps.
Love this! That said, wanted to try it on your website, can't report a bug that the bug reporting doesn't work on Safari MacOS... the submit button does not do anything.
Seems it needs some text to submit ( and entering just spaces doesn't count ) - ideally the Submit button shouldn't enable until there is valid text?
I added that when moving the bug around on macOS Safari it highlights weird sections of the web page, which isn't great.
Can you check it now? I've done some changes.
The submit button is not clickable until there is a text now. Thanks for the suggestion.
Built in fun mini game: How far can you get the bug to move (only counting after you release your mouse) without the popup appearing. Multiple clicks are allowed.
JetBrains does a great job with this by actually rewarding users who report bugs with free licenses and such.
> * Maybe sign in or create an account
If you want bug reports, don't do it. Have an email address when one can submit bug reports.
Kindle made it easy to report errors in ebooks, but I always found myself wondering if the errors I was flagging were even being looked at.
What made you go with this design choice instead of Google's "Feedback" button that lets you take a screenshot?
Can confirm, I prefer to stew in silent rage unless I absolutely need others to know.
Here's a quick bug report: I didn't know how I can check out the app you built. There were no links in your post. Only "Bugdrop.app", the name. I tried Googling it and it turns out Bugdrop.app is your actual domain. You should point that out: Bugdrop.app => https://bugdrop.app/
On macOS .app is the standard extension for any installed app.
I agree. Bug trackers should be easy to use. I wish Debian and ffmpeg would have better bug trackers.
The worst example I ever experienced was finding an actual flaw within some software with Trac as a version control system - somehow DD-WRT comes to mind - and I submitted a bug report with full reproducibility workflow and everything I could imagine. Essentially, the platinum standard for submitting a bug report in software development.
It was immediately rejected.
The reasoning? “Did not identify the relevant code in which the error occurred”.
Like… WTF????
Edit: confirmed as DD-WRT. I’ve never submitted another bug report to them again. And I’ve submitted hundreds of reports to other projects all over.
I confirm, I do it myself. but 90% of my submissions do not result in any response.
worse, support that is overly fixed on support sessions and calls to resolve bugs even when in the ticket it clearly states it's not reproducable, only a restart fixes it etc.
Take my logs and everything you get but ffs make it observable enough so that you don't waste my time.
This sounds neat! Do you have a site that describes how it's added to an existing project?
Not OP but, the website is bugdrop.app
FAQ says "The Bugdrop snippet is tiny and loads asynchronously"
So, you add a snippet of JS to your site.
Thank you. It's a simple setup—just copy and paste the JS snippet into your website. I'm also considering creating some video tutorials soon to make it even easier.
I imagine it's been quite difficult to educate users to use this tool?
> Even non-technical users click it just because "the little bug looked fun."
So you want non-bug reports from non-tech people. Why?
From my experience, exactly those reports are the ones that will never be addressed.
nice work, sounds like a decent niche to tap into for the right clients
There's the other side of the coin of reporting bugs besides initial friction: if the user feels like the bug reports end up in a black hole, then they will disincentivized from doing so.
What happens after the user files a bug from their point of view? Is there a follow-up, or is it like throwing a message in a bottle?
I'm thinking of adding an option for users to leave their email for follow-up after submitting a report. That feature should be available in the next couple of days.
yes, Kate editor is a classic example. one clicks the report a bug link in-app and immediately gets a login page. no one has time for this sort of thing. it indicates a disinterest in getting bug reports, making people do homework to report one. i switched editors and got back to work.
The first job I had as a software engineer was at a trucking company that had a desktop Swing application. If an exception happened, the user would get a pop-up with buttons to email support the stack trace or cancel. The email went to all the IT staff and someone would usually reply within an hour, often with a fix.
The engineering work was atrocious looking back. I probably fixed 50 random NullPointerExceptions in my 3 years there this way. But, it was one of the most productive places I've worked at because everything was done simple and there were no barriers between users and developers.
Great idea, not working on iOS Safari.
This looks like bugherd.com
I love this, and I'm so glad it has resulted in more people filing bugs. That said, there is a larger problem going on here that has yet to be addressed by the software industry as a whole. And that is that "bugs" (and "filing" bugs) is a very complex thing. It's not just one thing, it's many, many things. And until we face that and provide a holistic solution for "it", it will continue to be an existential problem.
Here's a selection of the different kinds of complexity with "bugs":
- Type. Is it a backend or frontend bug? A network bug or an infrastructure bug? An internal or external bug? Is it a "not considered a bug" bug? Is it a bug in documentation, training, intuitiveness, etc? A product- or feature-specific bug? A location-specific bug? A user-specific bug?
- Context. Is the user even capable of giving you enough context and information for this bug report to be usable? If so, is automatic? If not, will the user simply give up reporting when this becomes difficult?
- Communication. How does the user even report a bug? (I regularly try to file bugs with every tech product I use - because they are constantly riddled with end-user bugs - but I spend hours trying to dig up some way to contact the company to report the bug, and when I finally can contact someone, they refuse to even take my bug report, because it's not one of the read-from-the-script-customer-service responses/actions. And if the user does eventually get in contact with the company, is the developer (or anyone else) even capable of communicating with this user to get more information or inform them of a fix?
- Visibility. Quite often, users will experience bugs, and maybe one report comes in about them. This is then captured by customer service or someone else, and maybe they file a ticket. But then for each subsequent request, they just tell the customer they will record it and then.... don't send it to anyone, because they've already sent one such bug and assume it's being fixed. So the developers have no idea how often this bug is actually happening. Often when bugs are reported the devs aren't informed at all.
- Impact. Is it just affecting a single user, once or twice, in a niche setting? Is it affecting the same user all the time? Is it affecting a subset of users? All users? Is it affecting all users, but core functionality still works? Is it significantly affecting core functionality? Is it affecting core functionality but there's bigger issues going on so it's actually less of an impact? Are the developers even capable of understanding the impact? (how many of you know exactly how much each specific function affects the business?)
- Prioritization. We all have ticketing systems full of hundreds of tickets that sit in the backlog never to be fixed. They're annoying, or difficult, or unsexy, or they're not a new feature. Sexy bugs get prioritized, unsexy bugs sit in the trash heap.
- Fixability. Even if all of the rest is provided for... how difficult or easy is it for a developer to fix? Is the developer capable of contextualizing it and making use of the information? Do some of them have difficulty reproducing it, while others don't? Do they have all the training needed on all the systems involved in order to effectively triage/investigate/troubleshoot? Are they given dedicated time each development cycle to fix bugs? Are they even able to track down who is responsible for "fixing" the bug, what with the modern mess of interdependent microservices and siloed development teams? Will they be implementing regression tests to make sure it doesn't come back? Are you rewarding them for this work, in addition to the rewards for "sexy work" (new features implemented, cost saved)?
Yes, getting users to file more bugs is fantastic! But that is quite literally the tip of the iceberg.
Okay but what have you built?
Why not a video snippet? Why a note?
About 90% of day-to-day users won’t bother recording a video—plus, most people aren’t even aware of the browser’s screen sharing feature and may feel uneasy about what it’s doing. So in my opinion, a simple note is the best way to go.
this sounds like a vital improvement.
Every bug I encounter in my favorite game I do not report because they want:
* My email, yet again.
* A long form
* A bug description rather than a narrative of what I experienced
You write that "reporting bugs is usually a terrible experience". I find bugs ALL THE TIME, and yet, when I even try to find a way to contact ANYONE, let alone a developer, they leave no door open at all. No method, no form, no contact name, no nothing. I (along with many, I presume), actually want those companies to excel. I WANT to let them know what to fix. But, they just don't want to hear about it. Really sad I think.
In my experience it's because the companies have not hired any persons whose job is to triage bug reports. People do find bugs all the time, and making it super frictionless to report bugs will result in a deluge of reports. Some reports will be outright spam, some could be mistaking a feature for a bug, some could be duplicates. Someone needs to do the triage and try to reproduce before the issue is forwarded to developers. Few companies have the role of Quality Test Engineer (QTE) to do this job; most don't so they have no means to triage the bug reports.
The only exception is indie apps I pay for on the App Store. There is usually only one or perhaps two people behind it, so by definition that person is SWE, QTE, PM and several jobs rolled into one. And this is unsustainable unless the app is paid.
Wait... Isn't that what AI is for? To do that for "free" and removing the time an actual person has to spend on it? Separating the spam and duplicates, etc?
The difficult part is the step of reproducing the bug. Will companies trust AI enough to allow the AI to operate on their UI, according to instructions written by bug reporters who are strangers on the internet?
I think if you take for example apps on the Atlassian Marketplace, probably all of them have an easy way to contact them (Probably because they get Jira for free, granted).
I develop for iOS and Android. All my apps have a Send Feedback button which opens an email in the user's default email client with my address in the To field, pre-filled subject line and some diagnostic info in the body (things like version number, device type, iOS version etc). I get all my bug reports and feedback that way and respond to them via a reply email when I have released the update to fix it.
I had really simple feedback form in my Android app that was just text area and submit button. Then some ashole tester from Google put @ in it and suddenly I'm collecting PII. It was easier to just remove the feedback form.
And that is why companies use telemetry. As privacy advocate I still let telemetry to be collected as long as it is transparent. And I can filter it if there is something too disturbing.