Introduction to Book Sprints
From Aspirationtech.org Wiki
"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
