After shipping a few SaaS products, I noticed a pattern: Bugs? Yes. Bug reports? No.
Not because users didn’t care but because reporting bugs is usually a terrible experience.
Most tools want users to:
* Fill out a long form
* Enter their email
* Describe a bug they barely understand
* Maybe sign in or create an account
* Then maybe submit it
Let’s be real: no one’s doing that. Especially not someone just trying to use your product.
So I built Bugdrop.app - It’s a little draggable bug icon that users can drop right on the issue, type a quick note, and they’re done. No logins. No forms. Just context-rich feedback that your team can actually use — with screenshots, browser info, even console logs if they hit an error.
And weirdly? People actually use it. Even non-technical users click it just because "the little bug looked fun."
I didn’t want to build another "feedback suite". I just wanted something lightweight, fast, and so stupidly simple that people actually report stuff. If you've ever had a user say “something’s broken” and then ghost you forever, you probably get where I’m coming from.
What I’m most proud of? People are actually using it. And their users? They’re actually reporting stuff. Even non-technical ones.
Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects. Not trying to sell you anything — just sharing something I built to scratch my own itch.
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’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.
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.
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.
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.
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...
>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.
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 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.
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.
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.
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.
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.
Yes it still is. I made a reproducible example, try it out.
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 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.
If a game just sends info about a crash I couldn't care less.
The UI has the best productivity-focused design I've ever seen in any GUI application. And its a game. Absolutely incredible.
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.)
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.
The sad part is that their cloud services also often don‘t support basic features which their self hosted software offer…
[0]: https://discussions.apple.com/welcome [1]: https://discussions.apple.com/community/macos/sequoia
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.
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.
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.
I’d always reply though, usually with something equally terse.
As a developer sharing my code online, I don't even know where to begin answering that.
This is typical non-tech spam.
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?
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.
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.
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.
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"
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)
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.
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.
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! :(
Counter-counterpoint: Oh well
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.
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.
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.
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.
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.
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.
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. :)
Possibly disclosing sensitive information (which the user may not realize).
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.
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.
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.
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)
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 :)
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
But, anyone who took the time to write bug-free code went out of business decades ago.
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
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 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.
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.
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.
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'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 also just got a first response about a bug I reported 5 months ago,
It really depends on the author
It is an approach, for sure.
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.
A) only pay for perfection and
B) experience zero friction or cost in moving services?
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.
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 :)
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
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.
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 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?)
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.
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.
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. :)
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.
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.
I'm aware of the issue in mobile devices too, will push an update later tonight to fix it.
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!
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.
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!
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.
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 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.
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.
It's the reason apple became apple, even though I don't think the iPhone is intuitive today.
It doesn't have to be difficult. It just has to be not easy.
The other method I used is to have audit logs, identify when there are errors in certain steps.
If you want bug reports, don't do it. Have an email address when one can submit bug reports.
On macOS .app is the standard extension for any installed app.
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.
FAQ says "The Bugdrop snippet is tiny and loads asynchronously"
So, you add a snippet of JS to your site.
Take my logs and everything you get but ffs make it observable enough so that you don't waste my time.
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.
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?
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.
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.
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
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.