In addition, in my experience maintaining a developer tool, an outsized source of bug reports is Linux users reporting already fixed issues in their outdated distro packages, or even problems introduced by their packager (e.g. flatpak/snap permission problems). And they typically won’t identify the version despite clear instructions in the issue template asking for the debug output containing everything I need, including the version.
If you support distro packaging of your software (which you should, since it should ideally reduce the load on you when it comes to triaging bugs) and users are coming to you with distro specific bugs then you should:
- Immediately close issues where the user has indicated that they did not test against the latest version or where the user has not answered the question "did you reproduce this issue with the current version of the software built from source?" (You should just automate this)
- If users continue pestering you and they seem to come from a specific distribution: complain to the maintainers of the distribution and ask that they inform their users of the proper bug reporting channels.
New users are coming to linux on a regular basis and they're coming in with a windows mindset. It is important for the smooth functioning of both linux distributions and software projects to make users aware that the proper channels for reporting bugs they experience when using software which was packaged for their distribution is the distribution's maintainers.
Users need to be made aware that unless they're compiling directly from source and using a supported version then they have no business going to upstream with their bug reports.
You may think this is harsh but if you get backlash, distributions should have your back on this (they usually do have information somewhere to inform users that bug reports should go to them first). I recommend any open source project take this stance when it comes to bug reports. If someone finds a real bug and they are certain it's not one caused by their distribution then they can easily build your project and reproduce the bug there.
(Aside: If you are providing a library then an appropriate level of API stability is a must have if you want people to be able to actually test bugs in a newer library version.)
I strongly disagree - I'd rather all my users filed their bugs directly on the upstream issue tracker for my projects so that I can get a proper view of what bugs are being encountered. If there are steps to reproduce then most of the time it will be a lot easier for you as the developer to just check if the bug still happens with the latest version than having the user or packager build it themselves. Don't expect users just have a build environment laying around or can quickly set one up. Don't expect that building the latest version is always easy on every distribution.
If its not easy to reproduce or if there are no reproduction steps then sure, ask for more information. It's also OK to refer to a distribution bug tracker if the user is not able to produce a useful report or if you suspect there is a packaging issue, but doing that for all reports of problemsx with distro builds, especially when using automation, is disrespectful of the time the user has spent on reporting the bug. So sure, you can do that (you don't owe users anything after all) but I think its rude and will only turn potental future contributors away. I'm definitely glad that that is not how most projects handle user reports.
If you are being overwhelmed by user reports then maybe you can find some dedicated people from your userbase that would be willing to help with bug triage?
> Don't expect users just have a build environment laying around or can quickly set one up. Don't expect that building the latest version is always easy on every distribution.
In the case when a user is not technically skilled enough to test for the bug in the latest version themselves they should go to the maintainer whose job it is to be able to do that.
> but doing that for all reports of problemsx with distro builds, especially when using automation, is disrespectful of the time the user has spent on reporting the bug.
What? How is it disrespectful? They're helping their distribution and their distribution should be forwarding the bug onto you if it's not their fault.
In fact, if the distribution is aware of it then the user is more likely to get a hotfix sooner than if they go straight to you.
> So sure, you can do that (you don't owe users anything after all) but I think its rude and will only turn potental future contributors away. I'm definitely glad that that is not how most projects handle user reports.
It is actually how most old style open source projects operate. If you're happy to accept direct bug reports which are either already fixed in the latest version or which may be distro specific issues then go ahead. Please don't burden every other project with this kind of noise by making it clear that this is a project specific policy.
Don't blame the user here - your bug reporting template should have users declare what package version they're using so that you can easily tell them they're on an outdated package. Flatpak is usually a boon in this regard since you can ensure your users are all on the latest packages, though you're making the tradeoff of having to deal with any Flatpak-specific bugs (which I'd say is a decent tradeoff for solo maintainers).
> your bug reporting template should have users declare what package version they're using so that you can easily tell them they're on an outdated package
Of course I do that, and I said so. I do everything I can to make it trivial for users to give me all the information I need. They just don't give a shit. Some people won't read.
(And the extra irony here is that my original comment already mentioned issue template asking for everything, yet you didn't read it and jumped in to tell me "don't blame the user".)
Edit: I should also mention that this is FOSS work. I’m doing free support for these users who supposedly shouldn’t be blamed for wasting my time.
Bug templates help, of course. But people do still just dump the wrong stuff in until the report is accepted. Like some kind of OS version in the App version field, for example. Or some ambiguous thing like "latest". Or copy/paste from an existing bug report from some other person. You can see this on many public repos.
> Like some kind of OS version in the App version field, for example.
Oh, I would be grateful for even that. Often enough, the bug template is simply deleted, the last line of the error in non-debugging mode is pasted in along with a "doesn't work"; or just "doesn't work".
While I don't do this intentionally, I do use a native Android app (fasthub) to submit issues. So far as I know, there isn't any GitHub app that has support for issue templates. Occasionally I'll submit an issue without remembering to check for a template first, though I usually remember before actually submitting.
