Craig Silverman had a fascinating column last week about changes that Slate has made in its corrections policy in the wake of an embarrassing dustup with Politico. Here’s Craig’s pithy summary of this bizarre Escher-esque episode (which I also wrote about at the time):
In July, Slate published an article that provided evidence that Politico was routinely scrubbing errors out of its stories without adding a correction or similar notice for readers. Slate’s story, of course, was noticed by many journalists and many of us, myself included, weighed in with criticism and reaction. Then the tables began to turn: Politico pointed out several mistakes in Slate’s reporting and, in the end, Slate admitted that its correction policy had a provision that allowed for it to scrub factual errors from stories without the addition of a correction. (Provided that the error was spotted within twenty-four hours of publication, and it was spotted by someone at Slate.) Pot, meet kettle.
Slate is not the only publication with a post-publication window for tinkering with stories. At MediaBugs, we keep encountering this issue — as with this bug filed about a New York Times story earlier this summer. If you read that discussion, you’ll see a Times editor admitting the paper made substantive changes (though not technically the correction of an outright error) to an article after it was posted on the Web. Does the Times have a window, like Slate’s, in which it considers it okay to alter published articles online? How about headlines? Both Slate and the Times have always been extra meticulous in thinking through their approach to corrections, yet this post-publication change policy is a problematic area for both.
As a result of the Slate-Politico fracas, Slate has now decided to close its 24-hour window. This seems to be the upright, ethical response. It’s plainly well-intentioned and carefully thought out. But I think it’s the wrong direction to go: it’s a step backwards. It continues the tradition of allowing the limitations of print-think to govern our online behavior. The Web lets us improve our stories after we publish them. Why should we tie our hands?
We do so, of course, out of a sense of accountability. We don’t want to seem to be pulling fast ones on our readers. We don’t want it to appear that we’re “scrubbing” the record, as Silverman puts it.
There is a simple solution to this problem: Throw open the windows — and keep them open! Let yourself make changes; just don’t hide them. The same technology that lets us keep tinkering with words we’ve published also lets us store and display every alteration we make.
Instead of agonizing over the duration of the period in which we allow ourselves to change an already-published story, we should just be transparent about all the post-publication changes we make. Let’s give readers the “history” of our articles the way Wikipedia shows all the changes to each of its pages. As James Bridle puts it: Everything should have a history button!
This achieves two useful goals at once: It frees your hand to keep improving your articles even after you’ve published them, which is one of the great advantages Web publishing offers over print; and it makes sure that your readers will never think you’re hiding anything from them. Most readers will never need or want to see the revisions you’ve made; they just want to read the current version of the story. But in the rare case that someone raises a question or a dispute about a change, the record will be public.
If and when there are major substantive errors that you need to correct, you can still go the whole distance and add a traditional correction notice to any page. But if you’re fixing small errors or little details that don’t warrant that, you wouldn’t have to bother.
The technical hurdles to such an approach are minimal; most modern content management systems store all the revisions to each story in a database anyway. There’s a small amount of design work in figuring out how to expose the revisions to your readers. But it’s not a hard problem. I’m already showing all my revisions here on this blog — just look at the bottom of the full-page version of this, or any, post. (And if you run WordPress, you can install the WordPress Post Revision Display plugin too if you like!)
I’m firmly convinced that over the next few years this practice will become as commonplace in online publishing as “print this page” buttons and comments. So my challenge to Slate, the Times, and every other online publisher is: why not become a leader in this realm? Stop closing your “windows.” Instead, open them up and show your changes.
- September 27, 2010 @ 06:22:32 [Current Revision] by Scott Rosenberg
- September 27, 2010 @ 06:21:58 by Scott Rosenberg
There are no differences between the September 27, 2010 @ 06:21:58 revision and the current revision. (Maybe only post meta information was changed.)