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.