Archives for June 2011

New York Times public editor Art Brisbane today addresses an issue that MediaBugs and I have been talking about for a year: the need for news organizations to maintain a record of the changes they make to published stories.

I’ve argued that posting such “versions” of every news story — the way Wikipedia and every open source software project does with their own work — would help newsrooms regain public trust and free journalists to update their work more vigorously while staying accountable.

Brisbane seems to agree, but sounds doubtful that the Times is going to do this any time soon.

Right now, tracking changes is not a priority at The Times. As Ms. [Jill] Abramson told me, it’s unrealistic to preserve an “immutable, permanent record of everything we have done.”

I know the Times has tons of claims on its resources. Jill Abramson has a million demands to juggle. But let me respectfully dispute her “unrealistic” judgment.

Versions of stories are just data. For the Times, or any other website, to save them is a matter of (a) storage space and (b) interface tweaks to make the versions accessible. Today, storage is cheap and getting cheaper, and Web interfaces are more flexible than ever.

Really, there’s nothing unrealistic about preserving an “immutable, permanent record” of every post-publication change made to every story.
Wikipedia — a volunteer organization run by a variety of ad hoc institutions — can do it. Any WordPress blog can do it. It seems peculiarly defeatist for our leading newsroom to shrug and say it can’t be done.

By making story versions “not a priority,” the Times is essentially abdicating its longstanding status as our paper of record as it makes the transition from paper to digital. I doubt that’s what its leaders intend to do. The more they ponder this, the more I think they’ll see that a versioning system for news is not only valuable but inevitable.

The journalism industry ships lemons every day. Our newsrooms have a massive quality control problem. According to the best counts we have, more than half of stories contain mistakes — and only three percent of those errors are ever fixed.

Errors small and large litter the mediascape, and each uncorrected error undermines public trust in news organizations. In Pew’s last survey in Sept. 2009, only 29 percent of Americans believed that the press “get the facts right.”

Yet the tools and techniques to fix this problem are known and simple. I’ve been working in this area for the last two years. Here’s a distillation of what I’ve learned: three basic steps any online news organization can take today to tighten quality control, reduce errors and build public trust.

Link generously

A piece without links is like a story without the names of its sources. Every link tells a reader, “I did my research. And you can double-check me.”

• Read more on the value of links: In Defense of Links.

Show your work

The news isn’t static, and online stories don’t have to be, either. Every article or post can and should be improved after it’s published. Stay accountable and transparent by providing a “history” of every version of each story (a la Wikipedia) that lets readers see what’s changed.

• Read a longer argument for the value of versioning.
  Or try out the WordPress plugin.

Help people report your mistakes

The Internet is a powerfully efficient feedback mechanism. Yet many news organizations don’t use it. Put a report-an-error button on every story: It tells readers you want to know when you’ve goofed. Then pay attention to what they tell you.

• Get some report an error buttons at the Report an Error Alliance.
  Or use the MediaBugs widget.

Why aren’t these practices more widely adopted? Here are four reasons:

(1) Workflow and tools: In many newsrooms, especially those still feeding print or broadcast outlets, it’s still way too hard to fix errors or add links to a story for its Web edition. And content-management systems don’t yet offer corrections and history tools “out of the box.”

(2) Denial and avoidance: Other people make errors. Many editors and reporters don’t believe the problem is serious, or think it doesn’t apply to them. And most don’t understand how badly their Web feedback loop is broken.

(3) Fear of readers: Many journalists view readers as adversaries. The customer they feel they’re serving is an abstraction; the specific reader with a complaint is “someone with an agenda” whom they have a duty to ignore.

(4) Where’s the money? Many media companies are in financial free-fall. Correction systems and trust-building tools don’t bring in revenue directly, and they eat up product-development time and money.

These are serious obstacles. But journalists will never regain public trust unless we overcome them.

Ask journalists what sets them apart from everyone else sharing information online and we’ll say: We care about accuracy. We correct our mistakes. In a changing media economy that’s challenging the survival of our profession, we need to follow through on those avowals. Otherwise, we shouldn’t be surprised when Pew’s next biennial survey of public trust in the media shows even more dismal results.

[Crossposted from PBS MediaShift Idea Lab. This edition employs all three techniques I mention.]

[cross-posted from the PBS MediaShift Idea Lab]

A window of opportunity is open right now for online journalists to build accuracy and accountability into the publishing systems we use every day. To understand why this is such a big deal, first hop with me for a minute into the Wayback Machine.

It’s the mid-1990s. Journalists have just arrived on the web. They’re starting sites like Hotwired and Pathfinder, Salon and Slate. They’re doing good work, but also, inevitably, making mistakes. Their customary corrections routine — post a notice in the next edition or issue — makes no sense in the new medium, where stories are just files on servers or data in databases, and fixes can take effect instantly and invisibly.

Editors at the dawn of the web understood they had to be accountable for changes they made to published stories, and so improvised a routine for handling substantive corrections: Fix the problem; place a notice on the story page indicating that you’ve fixed it; and — this step was only taken by extra-conscientious organizations — add a notice to a separate page logging the fact of the correction (and linking to the corrected story).

>p>Fast-forward to the present. The web’s publishing environment is vastly more complex, flexible and elaborate. But when it comes to corrections, virtually every news site still handles things the way we did 15 years ago: Go into the story, often by hand (i.e., by adding to the body of the story text), fix the error, and append a correction notice to the story top or bottom. Then, if your site has a separate corrections-listing page, go into that by hand and add the notice there. Insert any cross-links. Republish the story and the corrections page. And you’re finally done.

The process is cumbersome, to be sure; it’s also not smart. Most publishing systems don’t actually “know” that the story has been corrected. There’s no data stored that distinguishes a corrected story from, say, one that’s been altered in some other way. The typical content-management system software package will track each successive edit or revision to a document, but it doesn’t distinguish garden-variety edits from formal corrections.

For years now, I’ve dreamed of a smarter publishing software tool that would handle corrections intelligently and seamlessly as part of the publishing cycle and editorial workflow, rather than as a clumsy kludge. One goal, certainly, is to make editors’ lives easier. If corrections can be handled with less fuss, maybe news sites will be less reluctant to make them.

But an even more important goal is to give journalists and the public better information about corrections. Once corrections are treated as data, developers can do things with them — say, allow readers to sign up to be notified of corrections for a site, individual story or story category; or create display boxes that automatically link to the half-dozen most recent corrected stories. The ultimate purpose of all this is for news organizations to demonstrate accountability and transparency to a public that views them with sparse and dwindling trust.

So when I read about the new Armstrong CMS project, I got excited. Armstrong is an effort by the software teams at the Bay Citizen and the Texas Tribune to build a new-model, open source publishing system for local news sites. It’s working off the highly regarded Django content-management framework, funded by a $975,000 grant from the Knight Foundation, and building on existing work already in use at the two sites.

The Armstrong project has a chance to create a new standard for corrections for the entire field of web journalism. I asked Brian Kelley, the Bay Citizen CTO who is a co-leader of the project, whether Armstrong had plans for corrections yet. He suggested that, because many organizations have different needs, Armstrong’s open plug-in and extension options might be the best way to handle the corrections process.

Maybe so. At MediaBugs we certainly plan to explore this route with Armstrong as we have with other partners; our MediaBugs widget and WordPress plug-in are already in use on a handful of news sites.

But there’s a bigger opportunity for the Armstrong community here: They can build a smart correction-handling process into the heart of the tool they’re creating. The best practices in this area are widely understood and agreed upon; why not bake them into the technology? No one, to my knowledge, has done this before in a free, open source publishing system. (If there are proprietary systems that do a better job, I’d love to hear about them.)

Here are the basic features I’d want any corrections tool to provide:

• Editors should be able to correct published stories by checking a box or clicking a button on an edit screen. If the system has a permissions hierarchy, then managers should be able to enable or disallow the option of making a correction.
• Editors who are correcting a story are taken to a screen or overlay that lets them enter the text of a correction notice. The software would automatically record the date and time the correction was made.
• Once the correction notice is entered, the editor is prompted to make whatever edits are required in the story text itself, and to save them. Editors would then have to republish the story, following whatever their site’s routine might be.
• Ideally, a corrections system like this is part of a larger scheme for tracking and presenting all post-publication changes to each story. The database would record the changes made to a story as part of the correction process in a special way — that is, it would know that this particular revision is not just any old change but a formal correction.
• Site designers and managers have the option of building a self-updating corrections page that automatically pulls in corrections notices and links back to the corrected stories.

That’s it! None of this is particularly challenging as programming or design work. My experience is that when I describe what’s needed to most developers, they’re not interested — the problem’s too “trivial.” Maybe it is — but not to the editors I’ve talked to, who groan about the pain their software inflicts on them whenever they try to do a correction the right way.

Each time we rewrite the software used to publish news on the web we have another chance to raise the bar for the whole field. I’m crossing my fingers that Armstrong will be the project to make smart corrections a reality.