Introduction to Book Sprints

From Ott09 Wiki
Jump to: navigation, search

"Book Sprint" based on the idea of a code sprint which is quite common

Get all of the experts in a room

Big part of writing a technical book is deciding whad doesn't go in

Goal: know who needs to write what

Who already has material that's licensed under the right licences

Working on wireless networks - open infrastructure (Tomas)


We realized that if you work on the community aspect you can take it a lot further if you work on community translations and such and Adam has really taken it to the next level there with FLOSSmanuals

FLOSSmanuals had built a collaborative toolset for manuals and used PDF generation and print-on-demand services like LuLu (Adam)

Start at 9:00 on say a Monday, write pretty much for 3 days continually, freeze on Wensday, put together on Thursday and clean it up on Friday

actually producing quality documentation (www.flossmanuals.net)

book about book sprints being worked on

2 days: 300 page 'introduction to the command line' with FSF, work with Mozilla on documentation for Firefox, bypass Internet censorship, etc.


3 goals:

1. to further the project that the manual is about

2. what we're really trying to do is just produce the content

3. produce a microcommunity around the content

quite an intensive social experience, helps long-distance collaboration later on


want to explore book spints in other contexts, not just technical: WOOF, swine flu, etc.

final product in biggest plus, way to concretely capture the goings on of, say, an unconference

aim of creating a knowledge for that subject, credibility becomes an issue with some areas

a book defines its own success, the scope of the content is defined by the people who write


wikipedia current debate on authorative versus participative content

most professional books are written by people who aren't the experts in their field

a book that may not be authorative is better than 100 narrow authorative sources -- distribution


question: style guide? answer: the group sort of decides what to do

in order to get things going, tell everyone to start writing on something that interests them

not burden them with rules, just let them get going

writing is a conversation

book sprint is a week long, the style, tone, and scope of the manual comes of age through the conversation, though the conversation

style guides are there for academics and people who feel like they need them

everybody else doesn't have to feel burdened by the rules

at the end somebody comes through and tidy up and make everything follow a certian style


style formation you can still do in a group dynamic sense

maybe just a 'many eyes' approach that allows people to see style discrepancies


question: the first day, critical for the project, how do you get everyone to agree? how do you get everybody on board?

facilitation is the key, also about overviewing all the content and getting the group to look at specific material and talk about it

index, glossary, and target audience done beforehand by email or otherwise -- actually start writing at 9:00 on monday morning

work out 2-3 hours who is going to write what, at the end of that time people start writing


hardest part is getting people started, walk into a room with people you don't know and face a blank page

it's all about making people feel okay, make them feel relaxed and confident

providing that kind of safe environment is critical


how is work divided?

FLOSSmanuals is based on reusable chunks (kinda like reusable libraries)

so a chunk is a chapter or a part of a chapter

strongly encourage people to leave their authorial egos at the door

think of themselves as collaborative writers and not single authors


i want a manual about Audacity, Sugar, whatever

people come to FLOSSmanuals to bring them on board with the book sprint

hard to find funding for, say, OGG theora and open video codecs


who does the prework? (index, glossary, target audience)

who sets the task? well, the guy who's passionate does

the process of selecting the people who go into the book can be important, too


goal is not to be authorative, this style is clearly good for the manual style

interested to experiment with other areas

is there an ideal group size? 6-8, according to Adam


must convince people that there is a need for this document to exist

other ways to contribute, translations, editing, ways to facilitate group

harmonize all the unterstandings of the content


question: copyright? licensing? languages?

coyright is on a chapter basis, who writes the chapter, everything else is a modification

CC-BY for most of the documents, GPL

language communities as opposed to major focus on tranlsation

how do you handle multilingual experts? have them work with each other?


not about authorship or ego, more about fun

it's really imortant to communicate and control the group dynamics

piggyback on existing communities, work with people who already know


with the book sprint the rule is to monitor the content

everyone must check in with one another to make sure that everyone is going in the same direction

you meet at the early stages to continue writing and have a sort on noisy