My favorite beers from the Great American Beer Festival

The Great American Beer Festival on Saturday was a blur. A delicious, beery, happy, blur. (See photo.) But! I did manage to scribble down my favorite beers in my beer diary (yes, I have one). The notes are probably not that useful ("yum! tasty! I want to drink it forever!" -- you get the idea...), but something about each of these beers made me fall in love. Oh, and I'm shamelessly biased toward Oregon beers, sour beers, and Belgian-style beers.

The buttons read: "I <3 Oregon beers" and "Oregon gives me wood" (from the Laurelwood Brewery in Portland)

Ching Ching by Bend Brewing, Bend, Oregon
Style: Sour with hibiscus and pomegranate
Notes: Pinky/orange color...simply amazing!
ABV: 9.5% (watch out)

Flemish Kiss by The Commons Brewery, Portland, Oregon
Style: "Bread" ale/pale ale
Notes: Slightly sour (just a hint!), lemony, fresh
ABV: 5.7%

The Stoic by Deschutes, Bend, Oregon
Style: Belgian quadruppel
Notes: Smells like a sour but finishes like a sweet Trappist
ABV: 11% (monastic strength)

Urkontinent by Dogfish Head, Milton, Delaware
Style: Belgian dubbel
Notes: Smells like coffee; brewed with rooibos tea
ABV: 8%

Red and White by Dogfish Head, Milton, Delaware
Style: Belgian wit
Notes: Sour and light, wine-y (aged in Pinot Noir barrels), really drinkable
ABV:10%

Abbey's Ale by Seven Brides, Silverton, Oregon
Style: Belgian quadruppel
Notes: A sour quad! Super drinkable, not puckering -- my favorite of the night! I had seconds (and I wasn't the only one...)
ABV: ??

Cockeye Cooper by Uinta, Salt Lake City, Utah
Style: ??
Notes: Light, cherry. Strong flavor but really unique. Delicious.
ABV: 11%

Diamond Kings by Brugge Brasserie, Indianapolis, IN
Style: Belgian quadruppel
Notes: Ages in Cabernet barrels -- tastes heavenly!
ABV: ??

Also of note...
Everything crazy and experimental by Short's, all the tart and tangy fruit beers by Rocky Mountain Brewing in Colorado Springs (think New Glarus' Raspberry Tart, but better), and Laughing Dog's  Anubis imperial coffee porter.

How the Knight-Mozilla Hackfest in Berlin changed the way I think about programming

#Hacktoberfest left me feeling mushier than this plate of potatoes and mystery green goo. I want to give a group hug to the world! (Image credit: Flickr user russeljsmith shared with a Creative Commons license)

At least week’s hackfest, I saw so many people celebrating the simple act of creating something that actually worked. It’s a marvel. But the coolest part about this -- and bear with me as I get all mushy here -- was how the act of making something brought people together.

People are makers. We can’t help it. But why? Why do people write, bake, program or paint? 

Here's my best guess: Our minds are lonely places where our thoughts languish. Until, that is, we can turn them into essays, pies, code, pictures -- something another human being can interact with. Making -- whatever it is you make -- is a way of connecting.

Once we know how to make something, we understand it better. We understand the person who made it better. And we understand ourselves better. By learning new ways to make things, we expand what we are able to imagine. The world of possibilities explodes.

Let me defer to my favorite episode of Radiolab to explain. Words. Go listen to it. Right now. Please.

For those of you disregarding my advice...shame on you! But here’s a quick summary: Words aren’t just words -- they are ideas. Before we have the words for a concept, we don’t have the ability to understand it. This has been shown with spatial concepts, time, empathy, all kinds of things. Our ability to think is inseparably bound to language.

What does this have to do with programming? At last week’s hackfest, I realized that programming is the same as writing. Or rather, I was able to map the programming process -- which, previously, I'd found daunting and unwelcoming -- onto a process of making that I find intuitive: writing.

Writing is thinking. And so is programming.
 
Language expands our capacity to understand and interact with the world as beings who can write and speak. And new skills -- for example, programming -- expands our capacity to understand and interact with the world as beings who can make and create. Last week, by getting better acquainted with some of the basic building blocks of a program -- code, logic, how different elements interact -- I was able to imagine possibilities that I couldn’t before.

And that’s why I want to learn more. Now I’m hooked.

I’m inspired to continue to expand my skills as a programmer -- which is really just expanding my skills as a thinker and a maker. So what are my next steps?

1. I’ve been working through Nathan Yau’s new book, Visualize This. I’m about halfway through, and my feet are appropriately wet with some Python, JavaScript and R. I want to keep going. Then go further.
2. I started an intro to computer science class from MIT’s open courseware. I really enjoyed the first problem set. A lot a lot. But then I stopped. So I’m going to finish it.
3. I want to apply what I’m learning through real projects. For me, that probably means data visualization.

Any other suggestions?

I’m amazed the diverse backgrounds of the #hacktoberfest participants. As Nicola mentioned in her blog, many people who are verifiable coding ninjas don’t have any formal background in CS or don’t work as programmers. So, it’d be interesting to, as a way of motivating others to take the plunge, collect stories about how people got into programming.

Here comes the audience participation part:

• How did you first learn to code?
• What was the first piece of code you wrote that you were really, truly proud of?

Maybe if more people heard those stories from seasoned (and enthusiastic) programmers, they might understand why it's a skill everyone can benefit from learning.

Keeping the MoJo Flowing: Blog posts I want to write about #hacktoberfest

While I was flying home from Berlin (through a very circuitous route: Berlin --> Warsaw --> London Heathrow --> Denver --> Boulder), I had nearly 24-hours of offline, device-free time to process some of the idea-explosion that happened in my head at the Berlin #hacktoberfest.  I'm back in Colorado now, doing Colorado things like getting an introduction to canyoneering and going to the Great American Beer Festival. But while I still have #hacktoberfest Berlin goodness flooding my brain, here are some discussions I want to continue:

1.  What does it mean to have a "mosh pit of the minds?" Creative innovation happens when you mash disparate people, ideas and fields together and watch the sparks fly. What are some other mind-moshes we could try (technology + gastronomy, journalism + adventure sports)?
2. The two functions of data visualization. Data visualization can be used to explore large and unwieldy datasets for patterns and meaning. They can also be used to communicate information quickly and simply. Are the tools that you need for exploratory and communicatory data visualization the same, or are they distinct?
3. Building the best "tool box." At #hacktoberfest, I kept hearing the concept of a tool box (for journalists, for developers, for storytellers, for data visualization creators) being discussed. (Note: I prefer "bag of tricks" to tool box, because it includes the tools and the skills you need to use them.) What are the different "tool boxes" we should be making, and how can we make them in an open, extensible way?
4. Instead of creating a "GitHub  for storytelling," what if we just started using GitHub as a reporting tool? I want to do a test case where, as I'm reporting and writing a story, I put all of my materials (notes, audio recordings of interviews, pictures, etc.) up on a GitHub repository. After the story is done (or during, if it isn't a sensitive story), make the repository public. Insta-open-reporters'-notebook!
5. What is a story to you? In Berlin, we talked over and over about the importance of stories. Data visualizations are meaningless if they don't tell a story. Information needs context and narrative. But what exactly are we talking about when we talk about stories? I'd like to crowd-source this by putting a call out on Twitter asking people to answer the question: "What is a story?" in 140 characters. Then it would be fun to make some visualizations of the responses.

I hope to turn each of these into a blog post in the near future. I have lots of ideas (seven more, at the moment) that I'll add to the list when I get a chance, but first -- to Denver, to drink delicious craft beers!

#MozNewsLab Proposal: The Infinite Story

The Infinite Story is a tool for opening up reporters’ notebooks and encouraging others to re-mix, mash-up, and extend news stories. Kind of like GitHub, but for storytelling.


MoJo Pitch: The Infinite Story from Jordan Wirfs-Brock on Vimeo.

BUSINESS BRIEF

The Problem
The news-cycle is dominated by an antiquated artifact: the article. Stories are imprisoned within this format. A story is a living, breathing entity that exists within a thriving idea-rich community. An article is a bounded, disposable snapshot of an unbounded story.

The Solution
The Infinite Story frees stories from the constraints of the article by hosting news on in a collaborative storytelling and engagement platform. It’s unique because it doesn’t treat writing and reading as two separate acts, but as elements of a single, iterative storytelling process.

Why would newsrooms use it?
To move forward in the digital age, newsrooms must collaborate - with fellow journalists, other newsrooms, and engaged readers. The Infinite Story helps journalists do their jobs while simultaneously fostering sticky engagement with a community of readers.

Who will benefit?
The Infinite Story is a tool for both readers and writers of the news. The storytelling process isn’t “report, write, publish, repeat” - it’s information gathering, synthesizing and sharing in a continuous loop. By opening up this process, The Infinite Story benefits news-makers and news-readers.

Competitors + existing tools/platforms
Tools for storytelling and information sharing exist, such as wikis, Wordpress, SharePoint, Dropbox, Buzzdata, DocumentCloud, Floss Manuals, Booki and Storify. Content management systems are designed to facilitate collaborative storytelling. There are opportunities for leveraging these tools, instead of competing with them, through feeds and APIs.

What will distinguish The Infinite Story, and be the key to its success, will be its ability to engage a community of open and collaborative storytellers.

DESIGN DOCUMENT

How does it work?
The Infinite Story has three components:

1. An open digital reporter’s notebook
Professional and citizen journalists can upload reporting materials - notes, audio interviews, video, photos, data files, links, documents, contact information. It helps reporters visually organize and tag information during the reporting and writing process, helps co-authors share materials on collaborative projects, and helps readers see how a story was created by getting a deep, behind the scenes view.

2. A visual story builder
Reporters can drag and drop elements from their notebook to construct a narrative and write around it, the same way Storify lets you write around tweets. Many writers use some kind of visual structure - for example, notecards with quotes/themes/scenes they can move around. This is a digital version of that process.

3. A community for social reading mirroring the functionality of GitHub
Readers can share a story or contribute primary sources of information. Highly engaged readers can “fork” the story by cloning the raw materials into a new projects they can extend by adding their own reporting and writing. The original author can track the life of the story - who’s sharing, adding, or forking.

Explore a prototype of The Infinite Story created around a real article + raw materials. [Caveat: I’m neither programmer nor designer. This is a *very rough* mock-up.]

When you are viewing a story, you can see a story view or a notebook view. This is the story view.

This is the notebook view.

Once you've forked a story, you see a "dashboard" view that includes a notebook and a story builder.

How could this leverage newsroom infrastructure?
Articles published in traditional online formats could link to The Infinite Story. The traditional article doesn’t need to disappear: It’s the window through which readers access the back-channels. The Infinite Story will create modular, exportable content. Writers composing articles can feed that content back into a newsroom’s CMS.

How would it be integrated into newsroom operations?
Many journalists I’ve spoken with expressed the need for a tool to organize their materials, both for their own personal writing process and for collaborative projects where they need to share materials. Because The Infinite Story integrates the writing and reading processes, reporters can use it at all stages storytelling. If they are using it to organize their reporting notes and raw materials, no additional effort is needed to share those with readers.

How would this be built collaboratively?
In the prototyping process, I incorporated story notes and media from a working journalist to guide the project design. This should be done on a broad scale with reporters, editors, newsroom developers, and news readers. The Infinite Story will be developed using an iterative process centered on user experience. The design process should recognize that writers become readers and readers become writers.

Challenges
The biggest challenges surrounding The Infinite Story are behavioral, not technological. Although reporters’ notes are designed to be open and transparent, there are reasons newsrooms might object to sharing them:

1. Sharing notes and interview recordings might compromise a story.
It could violate the trust or safety of a source. Or make it harder to continue reporting on the story by clamping up other sources. In some cases, competition might be a legitimate concern for limiting transparency.

2. Reporters’ notes are often cryptic and hard for anyone other than the author to read.
Reporters need to write things quickly, and don’t always have time to type up notes or transcribe interviews.

Issues related to (1) can be addressed with fully controllable permissions and access controls. Notes could be shared internally during newsgathering and writing, then publicly after the story goes live.

Issues related to (2) can be addressed by integrating tools journalists already use to do their work. The Infinite Story should free up time, not consume it. For example, if journalists are already using Flickr or Dropbox, pictures and files from those accounts should be fed directly into The Infinite Story.

Questions
How is this different from a wiki or CMS?
An essential part of journalism is taking complex information and turning it into a clear, coherent narrative. The Infinite Story values the integrity of narratives by allowing stories to be cloned/forked. A single story can give rise to many narratives. Each one should be respected.

Do people really want to mash-up stories?
There’s only one way to find out: Give people the tools to do it and see what happens. Story mash-ups present new opportunities for user engagement.

Reading list time!

Here are some things that have inspired my thought process for #MozNewsLab (many suggested by fellow labbers):

• "Open Source Data Journalism - Happening now at BuzzData," by David Eaves
• Video: JP Rangaswami on The Nature of Platforms (@ dgree.org)
• "Quick thoughts on journalism and version control," by Greg Linch
• "BCNI Philly: GitHub for News," by David Bachhuber
• Video: PyCon 2010: Writing Books using Python and Open Source Software, by Wesley Chun
• "The New Structure of Stories: A Reading List," by Johnathan Stray
• "Why We Need the News Environment to be Chaotic," by Clay Shirky
• "Why Stories Matter: The art and craft of social change," by Marshall Ganz

Use Cases for The Infinite Story

Participating in the #MozNewsLab is an amazing resource. It gives us an opportunity to open up our ideas - and our process - to scrutiny in the best possible way.

Here's some feedback I got from one Pippin Lee on my second blog assignment:

If you have time, here's a fairly quick, but interesting challenge that may help you focus any ideas you have...The goal: to give your product/idea a specific use case (don't be afraid of the edge-case subject either!). Here's an example. You can easily do this for all ends of the spectrum, but you'll begin to see how you are able to get deeper into understanding how and what you idea/product will face.

The goal: Define, "What is your point of view?"
The formula: [USER] needs [VERB] because [INSIGHT]

Here's what I came up with as use cases for my project [click to biggerize!]:


And here's a text version:

1. A team of journalists collaborating on a story needs to share, catalog and organize files and information because writing a story together requires melding of the minds on a tight deadline.
2. A writer working on a long or complex story needs to digitally organize reporting materials to track themes, insights and connections because she is working on many stories at once and wants to be able to dive back in to her thought process right where she left off.
3. An interested reader needs to connect to raw materials and resources because she wants to go deeper after reading a story and has questions that aren’t answered fully in the published story.
4. A newsreader-turned-newsmaker needs to access to reporting materials and deep background information because she wants to reinterpret them in the context of her own community by writing an expanded story on the same theme.

Are these the right use cases? What other ones can you suggest? As always, I'd love any thoughts/feedback.

Baking a Journalism Cake...Together

When Mohamed Nanabhay said this, he was talking about creating an environment for readers of news. But I think the same principle can and should be applied to and creating an environment for journalists and gatherers, tellers and sharers of news.

Simultaneous serendipity and purposefulness is the heart of any creative process. This is especially true for collaborations. Collaborations are so powerful - that is, when they don't succumb to hazards - because:

1. The sum truly can be bigger than the parts. (This is where purposefulness comes in.)
2. News ideas proliferate when disparate elements (people, ideas, circumstances, experiences) collide. Unexpected juxtaposition fuels creativity. More people, more new ideas.

Here’s the really exciting part: These features of the creative process happen whether collaborations are in-person or online.

This was my serendipitous Sunday.

My project - The Infinite Story, GitHub for Storytelling, whatever you want to call it - revolves around collaboration. It’s about freeing the journalism process from things that bind stories to one person or one team or one publication, ending stories' lives when that person or team or publication moves on to the next project.

So how do technology skills come into play? In a great (spontaneous and directed) Twitter-sation with @ChrisLKeller and @knowtheory last week, we discussed the collaborative processes and tools that teams of journalists use.

We realized: In journalism, in order to share the storytelling process, you have to share the news gathering process. You can’t bake a cake if you don’t have he ingredients. (You might still be able to frost a cake, but that’s a discussion for another day.)

Image by EpicGraphic

In my experience with collaborative investigative journalism, we've used a muddled system of Google Docs to aggregate reporting materials. It wasn’t a “new” technology for anyone on the reporting team. But logging and sharing all of our reporting material in it was new.

Adopting a new technology-based newsroom tool isn't necessarily a question of technical capacity, but a question of time and workflow.

If a tool is useful, usable and desirable, newsrooms will take the time to incorporate it into their workflow. If it's not, they won't. Infinitely more important than how technical you have to be to learn it is whether it enhances journalistic processes (does it reinforce the good habits, eliminate the bad ones).

So that is how I hope to address varying technical capacity. Yes, I want to make a tool that's as easy to use as possible (I'm thinking of a visual organization for story materials, plus a visual way to share/fork them), but ultimately the tool must enhances the newsroom flow:

Another project sketch...does visual = easy to use?

If adopting a new technology - and adapting your process to it - takes so much time that it doesn’t afford room for spontaneous discovery (and the targeted exploration of those discoveries), than it does more harm than good. But if it frees up time for spontaneous discovery, it's an invaluable addition.

My First Storify! Iteration and Journalism: A #MozNewsLab Discussion

Re-telling the narrative of a discussion is quite a challenge. Storify makes it a little bit easier.

Chewing on the #MozNewsLab Project Ideas

Reading the (50, when I last checked) 256-character descriptions of the projects the #MozNewsLab participants are working on was...
  intimidating
    inspirational
          thought-provoking
       reassuring
                daunting
      invigorating
               fun

One of the best things about reading them was how many connections and correlations there were between the ideas. So naturally, being the pattern-finding human that I am, as I read them I started describing them, tagging the, putting them into types.

This isn't a perfect system. Many of them overlap. And that's the best part.

The three strongest themes I saw were: content curation, social reading and beyond the article:

• Content curation - These ideas wrestle with questions of how we take a mess of information (whether it comes from news outlets, citizens, social media, any source, really) and turn it into a digestible flow. Examples: Manual Pinto, Charlie Pinder, Regnard Raquedan
• Social reading - These ideas try to make the reading of news more conversational. Or, to put it another way, more like how we actually talk/share/think about information with each other. Examples: Andy Jennings, Lucas Cioffi, Katie Zhu
• Beyond the article - The article as we know it is an artifact of the 20th century. These ideas try to take a "story" and turn it into the living, breathing, organic thing that it truly is. Examples: Engin Erdogan, Corbin Smith, Sedef Gavaz (also...me!)

There were about 25 themes I saw, including: adding context, annotation, data, visualization, mapping networks, reporting tools and semantic news. I put all the theme tags on a Google spreadsheet so you can view them (and change them, update them, do as you will).

This isn't a perfect way to organize these ideas...it's just a start. Next, I want to create a mindmap to visualize how all the different ideas and themes overlap and intersect. That's probably too ambitious for the time I have at the moment but...maybe one of the other #MozNewsLab participants will do it! (Ah, the perks of working with such a motivated group.)

#MozNewsLab is news/video/web/data/social/story

Yeah, world clouds are over-rated. But I still like them. Here's one created from the text of the 256-character project descriptions submitted by Knight-Mozilla Learning Lab participants. (Word cloud made using Many Eyes.)

Update: Here's a black-on-white version, and a grey background version, at @phillipadsmith's request. ;)

 

256 characters is actually a lot...

...for describing an idea. Here's my Knight-Mozilla Learning Lab project in 256 characters.

Project: “GitHub for storytelling.”
Goals: Foster open-source principles in journalism. Extend life-cycles of stories beyond their publish dates.
Key features: An open reporter’s notebook, version control, collaborative authorship tools and story-forking.

Now all I need is a pretty picture and I'll be good to go.

Breaking down barriers and opening up reporters' notes

One of the many insightful things John Resig said during his lecture on the attitude and philosophy that has made jQuery successful was: You must remove the barriers between your users and your product. Make it as easy as possible for them to get in and stay in, starting with your very first contact.

Part of this has to do with making the technology work as smoothly as possible, but perhaps an even bigger part has to do with the way that technology is presented and the community engagement elements surrounding it.

In week 1, I realized that the biggest challenges surrounding my idea -- which is a tool for opening up reporters’ notebooks and encouraging others to re-mix, re-mash, and extend the stories that come out of them -- will be around behavioral processes, not technology.

So this week, I’m going to apply John Resig’s advice to last week’s and do some thinking about what some of the behavior barriers might be to using a GitHub for storytelling.

In reality, even though reporters’ notes are designed to be open and transparent (how else are we supposed to be able to trust a journalist as a primary source of information?) there are dozens of reasons reporters might object to sharing them. Some have to do with egos. Some have to do with laziness. But two “categories” are legit:

1. In some cases, sharing notes and interview recordings might compromise a story.

This could be because it would violate the trust or safety of a source. Or make it harder to continue reporting on the story because other sources clamp up.

Then there’s the pesky issue of competition. Publications don’t want to get scooped.

2. Reporters’ notes are often cryptic and hard for anyone other than the author to read.

Have you seen a reporters’ notes? They look like some sort of Proto-Indo European line form language, not English. By necessity, they need to write things quickly, and don’t always have time to type up notes or transcribe interviews.

Issues related to (1) aren’t something that could -- or should -- be addressed for my idea. Issues related to (2) can and should be.

So how do we make that happen?

• Make new tools fit into the way journalists are already doing their work -- figure out what tools and processes they are already using to do reporting and integrate those as seamlessly as possible
• If a tool can make it easier for journalists to take and share notes, then it would be a real home run.

Figuring exactly HOW to do that is the hard part. Ideas?

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

The evolution of my Knight-Mozilla learning lab idea

Ideas have strange and interesting lives.

My idea has ultimately been boiled down to a single goal/statement -- Make information-based storytelling (aka journalism, the kind that happens in newsrooms) more collaborative.

To reach that goal, we have to encourage openness and transparency in the journalism process. So how can I do that without practicing openness and transparency in my idea development process? Um, I can't.

So, here's a rough outline of my idea process thus far, which I hope to update throughout the learning lab.

1. MoJo Challenge Submission - The Infinite Story

2. I work with data storytelling every day, and that produces tons of ideas. Ideas like...

• A GitHub for data projects -- what if you could take datasets that people have already worked on, cleaned, queried, manipulated, etc., and build off of that work? Data work is a huge task. It could be made more collaborative.
• Tools for data storytelling -- things that take the awesome data viz resources out there (Many Eyes, Tableau, visual.ly, etc.) and add content and storytelling elements. What if you could annotate data visualizations? Tie in social media feeds? Write a story around a data viz?

3. I've read a lot about collaboration. I'm obsessed with it. Enthralled. Projects like FLOSS Manuals get me really excited. How can we bring things like book sprints and collaborative authorship tools to traditional newsrooms?

4. One lesson I learned -- over and over and over -- as a journalism student is that only 10% of the reporting you do on any given story makes it to the "final" version. How can we tap the other 90%? How can we extend and nurture the lives of stories?

And all that led me to GitHub for storytelling. I don't know what it is. I don't know what it will look like. But I know I want to try it.

Prototyping the PROCESS: What would a GitHub for storytelling look like?

Aza Raskin’s lecture helped me realize that I need to prototype a behavioral process, not a technology. I’ll get there, promise. But first, some context around my project idea:

What excites me most about the Knight-Mozilla learning lab? The opportunity to foster the open source software community’s collaborative ethic in the journalism world.

This led me to a formative question: What would a GitHub for news -- a web-based tool for truly social information-based storytelling -- look like?


Next step? Doodling and brainstorming. Here’s how journalists traditionally create news stories:

That diagram is kind of a lie. Really, it looks more like this:

But what if it could look more like this:

It's journalism -- with forking! This diagram is messy. Downright ugly. But the point is: Stories aren’t discrete entities with a beginning, middle and end of life. That structure is an artifact of the 20th century news industry. (The marvelous Clay Shirky has some recent thoughts on this. Read them. Now.) Just like the post-artifact book Craig Mod proposes, I’d like to see a post-artifact news story. 

Print narrowed our definition of news: The web can open it back up.

What web tools could support this updated  workflow? For starters, a digital open reporter’s notebook for organizing information (notes, interviews, multimedia). Add to that: 

• community
• forking
• version control
• privacy control
• tracking of forked stories

and...

HOLD UP!

My brainstorming came to a halt, right here. (See the skid marks?) And it’s Aza Raskin’s fault: The barrier to change in a system often isn’t technology -- it’s culture and behavior.

I stopped sketching features of a software tool and started thinking about behavior and culture. Are newsrooms ready (although perhaps readiness is a luxury) for collaborative storytelling?

My first reaction was newsrooms won’t be open to a GitHub for storytelling. A lingering sense of proprietary culture and competition pervades much of the industry. As Shirky notes, this has to change.

In the new news ecosystem, it's collaborate or die.

The good news: journalism is inherently collaborative. The bad news: newrooms are 30% smaller today than in 2000. As the pool of “in-house” collaborators diminishes, newsrooms have two options:

1. Look outside for collaborators (journalists are doing this by integrating social media, made smoother by tools like Storify)
2. Get better at collaborating with the resources they have left

Collaboration can be improved.

To get there, I need to prototype the process not the product. How?

1. Look at successful journalism collaborations (great collaborations exist within the investigative news community, like ProPublica and other members of the Investigative News Network). What are they doing right? What could they do better?
2. Look at open reporter’s notebook projects. Or build one.
3. Start testing the workflow -- What would forking a news story look and feel like? Is it intuitive?

Then, and only then, can I start sketching software. (Hopefully, this will keep me from turning into a Swiss Army knife.) I have tons of work to do...better get started!