Put 8 people in a room for 48 hours and produce an 89 page (18,000 word) document! It’s called a Book Sprint. It’s rapid, collaborative authoring. I participated in a Sprint last week to crank out a guide for Google Summer of Code mentors. The endeavor was organized by GSoC admin, LH, and facilitated by Adam Hyde of FLOSS Manuals. Overall, the experience was surprisingly enjoyable and effective.
We did a bit of prep work via email before meeting. This included brainstorming on chapter titles and a rough index. The main hurdle here was to identify a clear focus and target audience to make sure we were setting a tangible goal. Then on Day-1, we introduce ourselves (other than by a few emails, most of us didn’t even know each other), got a brief overview of the process, and got to work. We probably spent another hour and a half on the index, leaving it intentionally flexible. And then we dove into writing parts of chapters that we felt inspired to write. It was a very loose, flowing process; you were encouraged to follow your muse. Adam had us using a customized wiki to manage the collaborative editing of chapters. Pro Tip: they’ll be releasing a new and improved interface called Booki in the next couple of months. It was critical that we did not assign chapters to individuals and work independently. The momentum and synergy that build from rapid cycles of writing-proofing-editing distinguish the Book Sprint from more traditional collaborative authoring practices. By the end of the first day, we had collectively written 12,000 words and estimated that we were 60% done.
On Day-2 we prioritized the remaining work, e.g., there were a few chapters that were still blank. By lunchtime we were ready to print out the first draft. We broke into groups of 2 or 3 and proofread sections that we had up to that point contributed to the least. This was an opportunity to tighten-up the prose and address the overall flow by dovetailing chapters and considering large-scale rearrangements. It was also an opportunity to appreciate the writing and editorial skills of my colleagues. A priori, I would not have guessed that proficiency in writing open source code correlates with writing skills in general, but our GSoC Mentoring team makes a compelling case. After we ran out of red ink, we regrouped to discuss our sections and the major changes we were considering. A few hours later and we were nearly done. A last minute dissection of a chapter. A couple passes over the entire document. Some final formating. Fin.
We had printed and bound copies in our hands the next day. Very satisfying. I’d recommend the process to any FLOSS project that finds itself in need of documentation (user manuals, developer guides, overviews of project context/field/scope, etc), but in short supply of time and resources. Sound familiar?