What is the equivalent of documentation for journalism?

[Ed. note, 7/25/2011: I thought this was going to be my official blog assignment for week 2 of #MozNewsLab, but then I wrote a new one and changed my mind. My official post is here. Sorry for the confusion!]

The value in smashing together two fields -- like ballet and football or journalism and software -- goes beyond the products created through unexpected fusion. The most lasting result is the change in perspective that occurs through removing industry-related blinders.

So during John Resig’s lecture, I concentrated on figuring out how each nugget he shared (and there were a lot) translates into journalism. If jQuery wasn’t a JavaScript library, but a magazine or a newspaper, what would John Resig have said?

My favorite four ideas:

1. jQuery uses community input to make decisions about future strategy and direction.
2. They make deliberate efforts to keep users after they’ve shipped products (a major time for people to forget about jQuery and move on).
3. They treat their users as a resource. The best users become contributors.
4. jQuery is successful is because it has the best documentation.

What would bizarro-newspaper-editor-John-Resig have said?

1. We base our editorial decisions on reader input: What stories do they want? What do they want the newspaper to look like?
2. We work to keep readers after they’ve read a story. (This is especially important with readers who get to stories through Facebook or Twitter. We focus on keep them here, and bringing them back, after they’ve gobbled up social media-fed links.)
3. We give our most engaged readers -- the ones making the best comments and giving us the best tips -- opportunities to be contributors.
4. Well, this one has a story...

I asked, “What is the equivalent of documentation for journalism?” on Twitter and got great feedback:

From @SaleemKhan,

“I can't think of a direct journalism analogue to code documentation, but the closest might be story notes.”
“Process journalism partly addresses it but isn't always ideal. News has legal/privacy issues coding does not.”

From @epilepticrabbit,

“Journalists keep records of sources and what they say, right? so documentation = these records. Maybe?”

From @k88hudson,

“Most efforts very low tech though. We're trying to experiment with a wiki for contributors this year”
“Internal documentation is necessary for student papers, because there is so little continuity (people graduating, etc)”

Two ideas emerged:

1. Documentation on the organization level -- how a publication works.
2. Documentation on the story level -- how it goes from idea to story. The reporting/newsgathering notes are the meat.

How does this fit in to my project? I want to create a tool that lets people, a) expose their reporting process, and b) extend the life-cycle of stories beyond their publishing date through re-mixing and re-mashing.

This isn’t possible without “story documentation.”

In fact, the problem I am trying to solve could be boiled down to:

Create a tool that makes it easy for reporters to clearly and simply share their “story documentation” (i.e. story notes and process).

Once we have that, the re-mixing and re-mashing can follow.

As I make my idea more concrete by moving into the prototyping phase, this will be my guide