[PaulHoule]

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.

[halpow]

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.

[ryao]

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.

[halpow]

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.

[ryao]

Once the not-stale label is set, the bot ignores the issue and will not close it again. At least, that is how it works for the OpenZFS bug tracker.

[account42]

> 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.

[ryao]

It should be obvious to him that it is not happening given that several contributors all responded no. As for closing the bug, no one has volunteered to be the one to do it.

[account42]

If it isn't obvious enough for any contributors to close the bug the it won't be obvious for an outsider.

[watwut]

Mine were closed by stale bot. They had merit and reproducible example. I just was not stalking the repo, watching it constantly to keep it alive.

[ryao]

Which issue? I can reopen it and mark it as not stale.

[watwut]

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.

[lukaslalinsky]

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.

[account42]

Yeah if I see a bot like that I just don't bother with bug reports to that project. Absolutely disrespectful to not even bother having a human look at the bug to decide if it can be closed.

[Aeolun]

I once saw one that only closed issues after two whole years of no response. I couldn’t help but think that was entirely fair.

[calcifer]

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.

[account42]

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.

[freeone3000]

For GTK, it’s all free work. You didn’t pay for it. You got the source for free. So yes, you are doing free work for the GTK team, just like anyone contributing to GTK is doing free work to fix it for you. This is fair.

[stalfosknight]

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."

[calcifer]

Criticism is fine, as long as it's constructive and not to the tune of "these volunteers are not volunteering to my satisfaction".

[stalfosknight]

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!!!".

[inejge]

> 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.