Tracking the newsroom bug-tracking idea

I want to return to the idea I floated a few days ago about bug-tracking software for newsrooms. The comments response ranged from “neat idea!” to “it’ll never work,” so let’s look it over again.

What I imagined was something similar to the way open-source software development projects manage bug reports. When people file bugs against such a project, they go to a publicly available online resource and enter a form that says “Here’s a problem I encountered,” and provide details. Different projects follow different organizational structures, but generally speaking, other developers will review the bug and try to classify it: Sometimes they’ll say it’s a duplicate and point to previous entries in the database that dealt with it; sometimes they’ll say it’s a simple problem and go fix it right away and close it out; sometimes they’ll say it’s a big one and leave it open to be dealt with in the future; sometimes they’ll say it’s a “known bug” that for one reason or another is never going to be fixed; sometimes they’ll say it’s not a bug at all.

For a newsroom, the idea is to provide a structure and a channel for reader dissatisfaction. You wouldn’t have to follow the software model detail for detail, but the general outline could be valuable: Provide a form for readers to enter complaints, one that requires them to present details. Post the complaint publicly as soon as it’s entered, and record the publication’s response in a reasonably prompt fashion — anything from “Thanks, we fixed the spelling on that name” to “we chose the phrase ‘private accounts’ because it is an accurate description of the president’s proposal, and the label was in wide use by supporters of the idea until very recently, so we do not plan to stop using the term.” The explanation is on record, and if other readers keep filing the same complaint they can simply be pointed back to the original answer. Spam? Just delete it. Letters to the editor that don’t have a specific complaint? Re-route them to the letters box.

The most common objection seems to be, forget it — this will become another free-for-all for political partisans to work out their agendas, another wide-open Internet forum that will degenerate into circular debate. Such forums already exist, to be sure; the point of a bug tracker is to avoid that outcome by choosing a narrower environment for the feedback that allows you to quickly aggregate and dispose of duplicate complaints, and that provides a public record of responsiveness and accountability. If 500 people all holler that you shouldn’t say “private accounts,” you can answer them once and be done with it — but you can point each individual complaint back to your explanation, so those people understand that you actually heard them and offered some sort of response. There’s a big difference between the silence of no response and “no, we’re not doing that, here’s why.” The latter won’t satisfy everyone, but it at least acknowledges that there’s been an exchange on the subject.

Ross Karchner proposed a somewhat different model based on wiki practices: “1) A publically viewable changelog, where you can see, in detail, the changes made to an article. 2) A place where the author(s) and editor(s) can discuss the changes needed and made. This is also in public view…” I’m not sure whether Ross means the changelog and the writer/editor dialogue to commence from the first time the writer composed a draft, or only upon publication. The former is, I think, too wide open — even a blogger has the right to compose a posting and revise it in private before choosing to push the “publish” button. The latter is fine — but since most reputable publications rarely change articles once they’re published, and note the changes as corrections if they do, then it’s just codifying an existing practice in slightly different ways.

As for the idea of trying all this out at Salon: Who knows, I might well advocate it, though my current on-leave status doesn’t put me in a good spot to work on it. But Salon has been dealing with the back-and-forth of online criticism of our work for 9 years plus. Whatever problems we may suffer from, a failure of responsiveness to online feedback is not, I think, one of them, and we have a pretty sturdy process for reviewing complaints fast and correcting them where needed.

I think this approach would pay off best for a newsroom that is having difficulty convincing readers that the publication is actually listening to them. If you showed the public that you were recording and responding to the issues they raised — whether you end up publishing a correction or simply saying, “We don’t think that needs correcting, and here’s why” — I think you’d start to bank some confidence and trust pretty quickly.

I’m not suggesting that this idea is the single, one-fix-solves-all-problems answer to the ills of journalism today. It’s a pragmatic, you-could-do-it-real-soon suggestion for beginning to deal with professional journalism’s biggest problem: the public’s loss of trust, which begins with the sense that media companies are big institutions that pay no attention to their own mistakes.