Categories
Free Culture

Open Literature HOWTO (Beta)

From the earliest mythology and folklore, literature has been written collaboratively. In the mass media era, movies and television shows are routinely written by teams or by a number of individuals working in turn. Open projects such as Wikipedia and the Linux Kernel show how to organise collaborative writing projects in a free and participatory way.

Principles

Projects Should Be Easy To Start

Anybody should be able to start a project. Registration is fine, and booting racist or homophobic projects out is fine, but the barriers to starting a project should be low.

Projects Should Have A Strong And Well Defined Purpose

Everybody needs to know what they’re working on. “A novel” isn’t good enough. “A 1200-page romantic novel in the style of Barbara Cartland but with ninjas and pirates” is a good starting point. The purpose of the project may change as the community grows. If people aren’t happy with the direction of the project they can fork it.

Projects Should Have An Owner

It seems counter-intuitive for projects that are meant to be collaborative, but projects need to have a “benevolent dictator” to guide them and to facilitate discussions. Usually this is the project’s founder.

Strong Modular Structure With Module Owners

A novel breaks down easily into chapters, a television series breaks down into episodes, and these break down into scenes and into lines of dialogue. The structure of the story is part of the design work of the project, and is one of the main ways of breaking down the project into manageable chunks, of division of labour.

Low Barrier To Entry To Projects

It should be easy to contribute to a project and easy to get involved. Contributions to draft and discussion areas of the wiki, and contributions to and involvement with the mailing list should be encouraged. Once an individual has contributed two useful revisions (for example)

High Quality Control With Good Feedback

Anything that doesn’t meet quality standards should be rejected with reasons and advice given.

Avoid Edit Wars

It is very easy to waste weeks on Wikipedia-style “edit wars”. Ensure that changes to pages are gathered on the discussion page or mailing list rather than on the main versions of pages. If page edits start getting out of hand the lead for the part of the project represented by the page should lock it and manage changes.

Avoid Walled Gardens And Sharecropping

To give people the confidence to contribute to a project make sure that they share the value of the project equally. Don’t lock the work away on a private website or use a noncommercial or non-standard licence.

Avoid “Consequences”

The principles and systems in this document are designed to ensure both that projects don’t end up as a glorified game of “consequences”, with text randomly following on from previous writing. A good example of a project that ended up as Consequences was Penguin’s “A Million Penguins” project, but many Wikipedia pages show that too much editing can lead to Consequences as surely as too little planning.

Project Roles

Project Lead

The “benevolent dictator” for the project.

Chapter, Scene Or Character Lead

The “champion” for some aspect of the structure of the story. Major characters, story arcs, locations and other features of the plot can all have leads. Each chapter should have a lead as well. Depending on the nature of the story there can be just a plot lead and a couple of character leads, or there can be many leads for each e.g. fantasy race or alien world.

Writer

Anyone adding text to the main story pages. There’s no reason for writers not to specialise in dialogue, description, or sketching out well-paced scene structure

Researchers

Any setting or character will need some research or fact-checking. This can be a good way for people who don’t regard themselves as literary to contribute to a project. Research tasks and information can be stored on the wiki.

Editor

Wikis and other systems need managing, and any writing benefits from review.

Proofreader

Spell checking cannot catch subtle grammatical errors, continuity errors or logical errors. Proofreading is very important and is a good way of capturing value from casual contributors or site visitors.

Project Resources

Mailing List

A mailing list is the focus for communication, discussion and co-ordination.

Weblog

A weblog is a good public face and entry point for the project. News, calls for contributions and samples of work from the project can all be blogged, and comments can be a good way of getting the public involved.

Wiki

The wiki is where the project will take shape. Part of the wiki will be the “Bible” for the story, like a TV Series “Bible”, part will be for drafts and ideas. Characters, locations, research, story arcs and story structure, chapters and collected ideas should all have their own pages.

Simple Projects

Simple projects may grow, but there are two simple models for such projects: iterative and sequential. Even simple projects need an agreed structure (which can be revised the same as large projects) and benefit from sketches and details co-ordinated on a wiki and in email.

Iterative

One writer produces a draft of the entire story. Other writers revise it in turn until a final version is produced.

Sequential

Each author is assigned a section of the story and completes it. Some editing may be required to fix any flow problems.

Technorati Tags: