Improving on bug reports
Off the Beat: Bruce Byfield's Blog
There's nothing like the comments to justify an article. After I wrote about the average user's difficulty with filing bugs, the responses came rapidly. Many agreed with me, or were willing to consider my comments plausible, but two with long histories of involvement with free software seemed only intermittently aware that any problem existed, and were more interested in faulting me for not suggesting more solutions.
As I said in the original article, my priority is timely articles, not contributing solutions. Moreover, in this case, I'd argue that voicing a problem that no one likes to discuss is a contribution in itself. Still, I prefer to contribute more when I can, so let me point out what should be self-evident:
Wanted: An interest in user feedback
First, a traditional weakness in many parts of free software is user-testing and feedback. Assuming the typicalness of Simon Phipps' dismissal of my first article as FUD, and his suggestion that the problem was "a sense of entitlement leading people to believe others should spring to attention and set aside their own motivations in response to unverifiable assertions of a bug," I think it safe to extend that generality to bug reports as well.
Admittedly, many users do contact free software projects with an attitude more suitable to a customer of proprietary software. However, to me it seems obvious that most of the effort to improve feedback from users has to come from project members, not end users themselves. After all, project members are the ones who decide how feedback is collected (or if feedback is even worth collecting). Expecting end-users to use applications like Bugzilla that are designed for programmers doesn't work, so alternatives are needed.
Just as importantly, efforts to explain how to write better bug reports have been made for years, and do not seem to help the situation. Most end-users are apparently not highly motivated enough to improve their reporting, which leaves the responsibility with project members.
The trouble is, as Aaron Seigo commented in a response on Google+, putting end-users and programmers together is not always the best idea. The two groups generally have little understanding of each other. Programmers have information and relationships that end-users do not, and end-users have little sense of how to shape their feedback. Consequently, programmers are apt to seem arrogant and unhelpful, and end-users clueless and over-demanding. With these attitudes, neither group is likely to learn any respect for the other.
Perhaps such interactions might be helped along by Aaron Wolf's suggestion that they are violations of a project code of conduct. However, that suggestion means filing another report, which might mean compounding the problem -- filing reports being at the heart of the matter to begin with.
Instead, the root problem seems to that people who can interpret programmers and end-users to each others are relatively rare. However, I suggest that those who can act as go-betweens are more likely to be found among the non-technical contributors to a project than among the programmers. If nothing else, contributors such as documentation writers are more likely to have experience already in being go-betweens.
If a project is truly interested in user feedback (and does not reject out of hand such feedback as a hopeless muddle not worth sorting through for helpful information), then perhaps a start is to give such go-betweens the active task of seeking out users in situations that are comfortable to the users.
For example, some project members could patrol user mailing lists and IRC channels, looking for problems and trying to tease out more details when a problem is described. Those who run project-associated web sites could poll readers for what they would like to see in upcoming releases. Some could keep track of professional reviews, and contact writers to learn more about their criticisms. Some might even arrange to meet end-users face to face in what Deb Nicholson would call a Spinach Con to observe as well as discuss, and get a little user-testing done on the side.
The motivation as much as the means
Such activities would require endless patience, to say nothing of a project willing to deal seriously with the results. However, they would make giving feedback much less intimidating to the end-user, while keeping programmers from having to deal directly with complaints.
An ultimate solution would be to integrate user-testing into a project's development cycle, but such a major change could be difficult to manage. If nothing else, user-testing would require a commitment to change that few projects show any signs of having.
Often, even minor changes such as the ones I mentioned may be too much for projects to maintain on an ongoing basis. For example, as Michael Meeks pointed out to me, LibreOffice designed a Bug Submission Assistant, a wizard that guides users through submitting a bug. As an initiative, it is worth trying -- but, as I write, it has been down for at least three weeks, which could be seen as indicating that hearing from users is currently a low priority in LibreOffice.
That, really, is the core of the problem. Imagining ways to capture user feedback is not especially hard -- but what is hard is to implement those ways and make them an ongoing part of projects .I can only hope that more projects will try.
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Offers 12-Year LTS for Open Source Docker Images
Canonical is expanding its LTS offering to reach beyond the DEB packages with a new distro-less Docker image.
-
Plasma Desktop 6.1 Released with Several Enhancements
If you're a fan of Plasma Desktop, you should be excited about this new point release.
-
SUSE Offers CentOS 7 Support with Liberty Linux Lite
SUSE's Liberty Linux support offering now includes CentOS 7, which means businesses won't be forced to migrate those servers for some time.
-
Ubuntu's App Center Finally Supports Local Installs Again
If you regularly download .deb files and would prefer a GUI method of installing, Ubuntu has your back.
-
AlmaLinux Now Supports Raspberry Pi 5
If you're looking to create with the Raspberry Pi 5 and want to use AlmaLinux as your OS, you're in luck because it's now possible.
-
Kubuntu Focus Releases New Iterations of Ir14 and Ir16 Laptops
If you're a fan of the Kubuntu Focus laptops or have been waiting for the right time to purchase one, that time might be now.
-
NixOS 24.05 Is Ready for Prime Time
The latest release of NixOS (Uakari) has arrived and offers its usual reproducible, declarative, and reliable goodness.
-
Linux Lite 7.0 Officially Released
Based on Ubuntu 24.04 and kernel 6.8, Linux Lite version 7 now offers more options than ever.
-
KaOS Linux 2024.05 Adds Bcachfs Support and More
With updates all around, KaOS Linux now includes support for the bcachefs file system.
-
TUXEDO Computers Unveils New Iteration of the Stellaris Laptop Line
The Stellaris Slim 15 is the 6th generation and includes either an AMD or Intel CPU