Comment by D13Fd 7 days ago
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.
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.
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.
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.
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.
I would defibitely file bugs with factorio because of the devs, but never found any. Truly amazing game.
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.)
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…
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
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.
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.
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.