Earlier this summer, Scott Rosenberg, co-founder of Salon.com and author of the new book Say Everything, received word that he was one of only nine winners of a 2009 Knight News Challenge grant. As soon as I heard the name of his project, I had a feeling it was going to be something of use in the realm of errors and corrections.
The project is called MediaBugs, and it hopes to find a better way of bringing the public and journalists together to correct errors. It will focus on working with people and media outlets based in the San Francisco Bay Area.
“In software, bugs are errors that cause programs to malfunction,” reads a FAQ on the project’s Web site. “A media bug is an error or problem that you find in a newspaper or magazine article, broadcast news report or online posting.”
At this point it’s important to disclose the fact that I’ve agreed to be an advisor for the project. I wasn’t involved in the grant proposal, and I have no idea how little or how much I’ll be involved, as the project is just starting to get underway. With that in mind, I thought it better to interview Rosenberg before we began working together. (By the way, Rosenberg is hiring an associate director/community manager.)
I caught up with Rosenberg yesterday on Gchat to ask him about the project and learn about his experiences with errors and corrections. Here’s an edited version of our conversation.
Craig Silverman: So, obvious question: where did the idea for this project come from?
Scott Rosenberg: I was working on Dreaming in Code, my account of an open-source software project, in 2003-4 and I was still managing editor of Salon, though I was heading off on book leave. One of my jobs was handling corrections. And I found that we tended to have lots of e-mails telling us about the same fix that needed to be made.
This wasn’t a problem when we were making a fix—I’d just point all the e-mailers to the correction. But in the instances where we felt, no, we were right, we weren’t going to fix, for whatever reason, I had to write back to all these people and explain. I always wanted there to be a single public explanation that we could point people to. Then I started to see how the bug tracker worked on the open-source project I was writing about. And I thought, what if we did that at Salon? It would be an interesting experiment.
That never happened—limited resources, I was heading off on leave, too many other, more pressing matters. But I blogged about the idea and it stayed in the back of my mind and it emerged when I thought about News Challenge ideas.
CS: So do you see the project incorporating specific lessons or practices from software bug-fixing? Or is it more of a source of inspiration?
SR: At this point, more inspiration and metaphor than a specific template. The interfaces for actual software bug trackers are way more complex and human-unfriendly than we’d want for MediaBugs. The key inspiration for me is the frame of mind with which programmers receive bug reports. They’re grateful! Their attitude is, “Thank you for pointing that out, because now I can fix it and make our product better.”
And that’s just so different from my own experience of decades in journalism—both in my work as a writer and reporter, when I’ve made mistakes, and in my work as an editor, when I’ve had to clean up after someone. Journalists still have this “mark of shame” feeling when someone brings an error to their attention. It’s understandable and human, but I think it hasn’t served us well.
CS: How do you see the site working?
SR: We’re going to be serving two distinct populations: members of the general public—let’s call them users, for the moment—and journalists. For the users, we’re going to try to make it as simple and easy [as possible] for them to post an error or “bug report.” The more information they can provide, the better. But at the start we’ll do what we can to fill in blanks.
We’ll also take the initiative at the start to contact the news organization or individual journalist involved and let them know that the report was filed—and we’ll invite them to respond. A lot of the time I think it will be a simple “OK, we’ll fix that.” Other times there might be a back-and-forth. We’ll do our best to keep the exchanges on track and civil.
And we’ll try to record the outcome—did a correction end up being made? Was the user satisfied with the outcome? Did other people who followed the bug feel the outcome was satisfactory?