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.
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.
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.
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.
The UI has the best productivity-focused design I've ever seen in any GUI application. And its a game. Absolutely incredible.
If a game just sends info about a crash I couldn't care less.
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.)
[0]: https://discussions.apple.com/welcome [1]: https://discussions.apple.com/community/macos/sequoia
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…