Discussions in unwanted places

Following my critique of Aaron Swartz’s WikiCourt proposal, Aaron e-mailed me to point out that most of my objections involved people messing up the WikiCourt process with complaints about the process itself. That could easily be fixed, he said, by removing all avenues for discussion.

However, WikiCourt would be dependent on outside input for submitting evidence, for challenging the validity of evidence, and for editing the Wiki page presenting the case. While none of these channels may be intended as an avenue for discussion, humans have frequently demonstrated that they will try to converse even in areas where discussions are not wanted.

Perhaps the most high-profile example is customer reviews of books on Amazon.com. Despite reviews often being presented in unchronological order, and despite Amazon.com specifically discouraging comments on other reviews, reviewers often engage in inter-review bickering. In some cases they will admit they hadn’t finished (or even begun) the book in question, but felt compelled to write a review so as to respond to claims made by a previous reviewer.

Another example is Petitiononline.com, which hosts petitions and allows people to record their support for them. The site also allows people to make a comment alongside their name; as a result, people often add their name to a petition so that they can make a comment opposing whatever the petition is asking for.

The saddest example I know of is Bugzilla, a Web-based system originally developed to track bugs and requests for enhancement for the Mozilla software, and now used for a variety of other projects as well.

By default in Bugzilla, when someone adds a comment or makes any other change to a bug report, everyone associated with the bug report will receive an e-mail message: the reporter, the assigned programmer, the QA contact, and anyone else who has registered their interest. This can result in a lot of e-mail being sent.

It’s not so much of a problem when Bugzilla is used by a small or professional team, because participants have social or disciplinary incentives (or both) to ensure everything they do in the system is productive. But when Bugzilla is used by a large mostly-volunteer team, as it is with the Mozilla Project, you get problems. People argue about whether something is a bug or not. They argue about its severity. They argue about its schedule. They plead for the bug to be fixed soon. They throw tantrums. They make long tedious comments no-one can understand. In short, they treat Bugzilla as a discussion forum.

As a result, over the past few years several of Mozilla’s best programmers have begun to ignore most or all of the e-mail they receive from Bugzilla, for the good reason that they’d rather be fixing bugs than wading through Bugzilla discussions. The correct response from Bugzilla’s maintainers would have been to make Bugzilla harder to use as a discussion forum, but instead they made it easier. They added linkable numbers for comments, making it easier to reply to them in new comments. They made the comment field larger, aiding long and rambling comments. They added a mechanism for quoting a previous comment when replying, aiding long and rambling conversations. And they could have turned off the quoting feature in the mozilla.org installation, but they left it turned on.

Each of these decisions appeared to be good and proper, as it improved the usability of Bugzilla for those writing comments. But the purpose of Bugzilla is not to collect comments, it is to track bugs. And the resulting blizzard of comments has made Bugzilla less useful for tracking bugs.

These changes could be reversed: making the system more difficult to use could improve the quality of discussions, though such changes would be highly unpopular. Another common tactic is to set up parallel forums for the kinds of discussion you want to keep away from the main forum: this is what MetaFilter does with MetaTalk, for example, and Wikipedia does with Talk pages. Such parallel forums don’t work all the time, but they work often enough to be useful.

Sometimes, though, as with WikiCourt, you don’t want discussions at all. And that’s the problem. With this social software stuff, discussions are something you have to try really hard to not have.

Comments are closed.