[HN Gopher] Show HN: Most users won't report bugs unless you mak...
___________________________________________________________________
Show HN: Most users won't report bugs unless you make it stupidly
easy
Most feedback tools are built like people actually want to report
bugs. They don't. Unless you make it dead-simple, or better yet - a
little fun. 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.
Author : lakshikag
Score : 144 points
Date : 2025-06-09 15:16 UTC (7 hours ago)
| nemomarx wrote:
| This sounds neat! Do you have a site that describes how it's
| added to an existing project?
| tln wrote:
| 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.
| LanceJones wrote:
| 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.
| mmsc wrote:
| 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.
| graypegg wrote:
| 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.
| airza wrote:
| 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.
| Sohcahtoa82 wrote:
| > 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.
| keyringlight wrote:
| 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
| Vilian wrote:
| It also leave a coredump, they can remove repeated
| entries and then filter by good comments
| mmsc wrote:
| >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.
| Sohcahtoa82 wrote:
| > 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.
| ryandrake wrote:
| > "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.
| Vilian wrote:
| 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"
| graypegg wrote:
| 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. :)
| gjsman-1000 wrote:
| 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.
| ashoeafoot wrote:
| Why not a video snippet? Why a note?
| pxtail wrote:
| 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.
| Supermancho wrote:
| 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.
| happyopossum wrote:
| So you:
|
| A) only pay for perfection and
|
| B) experience zero friction or cost in moving services?
| Supermancho wrote:
| I think trying to argue with the sentiment, misses the point
| entirely. I think we can all agree, bug reporting could use a
| renaissance.
| eastbound wrote:
| 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.
| pxtail wrote:
| 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.
| socalgal2 wrote:
| 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.
| StefanBatory wrote:
| So instead of getting a fix, you'll choose to be angry.
|
| It is an approach, for sure.
| vorgol wrote:
| > 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.
| PhilippGille wrote:
| Not a fan of made-up testimonials, but otherwise it looks nice.
| How do you prevent spam?
| I_dream_of_Geni wrote:
| 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.
| kccqzy wrote:
| 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.
| I_dream_of_Geni wrote:
| 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?
| eastbound wrote:
| 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).
| busymom0 wrote:
| 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.
| boricj wrote:
| 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?
| Rick76 wrote:
| 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.
| vorgol wrote:
| > 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.
| cosmotic wrote:
| 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.
| lupusreal wrote:
| 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.
| 0cf8612b2e1e wrote:
| 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.
| Vilian wrote:
| Fixing bugs don't create features, that upset execs
| cwillu wrote:
| 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.
| lkeskull wrote:
| I imagine it's been quite difficult to educate users to use this
| tool?
| 5040 wrote:
| 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.
| Mystery-Machine wrote:
| 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.
| OsrsNeedsf2P wrote:
| What made you go with this design choice instead of Google's
| "Feedback" button that lets you take a screenshot?
| paxys wrote:
| Okay but what have you built?
| mkarreth wrote:
| 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.
| sandbox01 wrote:
| 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.
| dvh wrote:
| 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.
| OrvalWintermute wrote:
| 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
| nicce wrote:
| 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.
| wittjeff wrote:
| 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.
| Oras wrote:
| 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.
| D13Fd wrote:
| 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.
| esafak wrote:
| Transparency in the form of a public ticket tracker would solve
| that.
| socalgal2 wrote:
| 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.
| YetAnotherNick wrote:
| 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
| sh34r wrote:
| 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.
| unclad5968 wrote:
| 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.
| n_plus_1_acc wrote:
| I would defibitely file bugs with factorio because of the
| devs, but never found any. Truly amazing game.
| PaulHoule wrote:
| 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.
| neilv wrote:
| 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.)
| kelipso wrote:
| 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.
| _wire_ wrote:
| 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.
| TheAceOfHearts wrote:
| 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.
| foobarchu wrote:
| > 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)
| bdangubic wrote:
| 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 :)
| qingcharles wrote:
| 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.
| SoftTalker wrote:
| > screenshots, browser info, even console logs if they hit an
| error.
|
| Possibly disclosing sensitive information (which the user may not
| realize).
| nailer wrote:
| 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.
| Animats wrote:
| 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.
| NooneAtAll3 wrote:
| 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?)
| bionhoward wrote:
| FYI, there's a bug with the bug, it doesn't move on mobile
| rikroots wrote:
| > 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
| ChrisMarshallNY wrote:
| 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.
| socalgal2 wrote:
| 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
| briandoyle81 wrote:
| 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)
| dmitrygr wrote:
| 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.
| solarkraft wrote:
| 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.
| shmerl wrote:
| I agree. Bug trackers should be easy to use. I wish Debian and
| ffmpeg would have better bug trackers.
| rekabis wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-09 23:00 UTC)