Change is good, but show your work: Here’s a WordPress revisions plugin

A couple of weeks ago I posted a manifesto. I said Web publishers should let themselves change published articles and posts whenever they need to — and make each superseded version accessible to readers, the way Wikipedians and software developers do.

This one simple addition to the content-management arsenal, known as versioning, would allow us to use the Web as the flexible medium it ought to be, without worrying about confusing or deceiving readers.

Why not adopt [versioning] for every story we publish? Let readers see the older versions of stories. Let them see the diffs. Toss no text down the memory hole, and trigger no Orwell alarms.

Then I asked for help creating a WordPress plugin so I could show people what I was talking about. Now, thanks to some great work by Scott Carpenter, we have it. It’s working on this blog. (You can get it here.) Just go to the single-page form of any post here (the one that’s at its permalink URL, where you can see the comments), and if the post has been revised in any way since I published it, you can click back and see the earlier versions. You can also see the differences — diffs — highlighted, so you don’t have to hunt for them.

The less than two weeks since my post have given us several examples of problems that this “show your work” approach would solve. One of them can be found in the story of this New York Times error report over at MediaBugs.

An anonymous bug filer noticed that the Times seemed to have changed a statistic in the online version of a front-page story about where California’s African Americans stood on pot legalization. As first published, the story said blacks made up “only” or “about 6 percent” of the state population; soon after it was posted, the number changed to “less than 10 percent.” There’s a full explanation of what happened over at MediaBugs; apparently, the reporter got additional information after the story went live, and it was conflicting information, so reporter and editor together decided to alter the story to reflect the new information.

There is nothing wrong with this. In fact, it’s good — the story isn’t etched in stone, and if it can be improved, hooray. The only problem is the poor confused reader, who saw a story that read one way before and now reads another way. The problem isn’t the change; it’s the failure to note it. Showing versions would solve that.

Another Times issue arose yesterday when the paper changed a headline on a published story. The original version of a piece about Tumblr, the blogging service, was headlined “Facebook and Twitter’s new rival.” Some observers felt this headline was hype. (Tumblr is successful but in a very different league from the vastness of Facebook and Twitter.) At some point the headline was rewritten to read “Media Companies Try Getting Social With Tumblr.” Though the article does sport a correction now fixing some other errors, it makes no note of the headline change.

I don’t know what official Times policy is on headline substitution. Certainly, Web publications often modify headlines, and online headlines often differ from print headlines. Still, any time there’s an issue about the substance of a headline, and the headline is changed, a responsible news organization should be forthright about noting the change. Versioning would let editors tinker with headlines all they want.

I do not mean to single out the Times, which is one of the most scrupulous newsrooms around when it comes to corrections. Practices are in a state of flux today. News organizations don’t want to append elaborate correction notices each time they make a small adjustment to a story. And if we expect them to, we rob ourselves of the chance to have them continuously improve their stories.

The versioning solution takes care of all of this. It frees writers and editors to keep making their work better, without seeming to be pulling a fast one on their readers. It’s a simple, concrete way to get beyond the old print-borne notion of news stories as immutable text. It moves us one decent-sized step toward the possibilities the Web opens up for “continuing stories,” iterative news, and open-ended journalism.

How the plugin happened: I got some initial help from Stephen Paul Weber, who responded to my initial request to modify the existing “post revision display” plugin so as to only list revisions made since publication. Weber modified the plugin for me soon thereafter (thank you!). Unfortunately, I failed to realize that that plugin, created by D’Arcy Norman, only provided access to version texts to site administrators, not regular site visitors.

Scott Carpenter, the developer who’d originally pointed out the existing plugin to me, stepped up to the plate, helped me work up a short set of requirements for the plugin I wanted, and set to work to create it. Here’s his full post on the subject, along with the download link for the plugin. We went back and forth a few times. He thought of some issues I hadn’t — and took care of them. I kept adding new little requirements and he knocked them off one by one. I think we both view the end-product as still “experimentally usable” rather than a polished product, but it’s working pretty well for me here.

As the author of a whole book on why making software is hard, I’m always stunned when things go really fast and well, as they did here. Thanks for making this real, Scott!

If you run WordPress and like the idea of showing your work, let us know how it goes.