BOOK SPRINTS
XO Sprint
This BookSprint grew from an idea that a manual for the next Give One Get One release from the One Laptop per Child project may help with supporting people who purchase the laptop as if it were any other consumer product. In reality, the goals of the the One Laptop per Child project are to educate children, not to build consumer products.
The OLPC project aims to produce a low-cost, low-power laptop for students in developing areas of the world. Translation to additional languages is an important aspect of the project, and participants should learn to embrace open source philosophies of allowing use, changing, and modifying of the source, including instructions, information, and knowledge, for the software that runs on the laptop.
The Book Sprint became a workshop where subject matter experts shared their knowledge of the products, and writers shared how to write good user documentation. It was also a social experience where attendees formed a community of shared common goals and experiences. For the OLPC Book Sprint the attendees gave (up to) a week’s time to be curators of information housed in wikis and websites everywhere.
Funding
With attendees coming in from around the world and the need for them to sleep and eat while they write, it was necessary to finance their accommodations and travel. With three matching $1000 support pledges from vested organizations (RedHat, OLPC, and an individual donation to SugarLabs) plus the fundraising efforts of FLOSS Manuals, we provided travel and lodging and some meals for contributors. With five or six in-person contributors and at least twice that many contributing remotely, we were able to fund the BookSprint for about $4000 total. There are two books for sale as a result of the BookSprint, and a two-Euro markup on each book should help pay for these type of maintenance costs going forward.
Platform Development
For this sprint Aleksandar Erkalovic (aco) added status notifications to the editing interface. This meant that we could mark a chapter with an individual status such as 'to be proofed', 'needs images' etc.
The status markers worked well but provided a heavy load on the server due to the way we implemented them. Aco, as always, came through and rewrote the mechanism to make the load much lighter. The status markers were wonderful and assisted the process a great deal. Now contributors, whether remote or in real space, could see what needed to be done for each chapter at a glance.
Invite list
Attendee selection and invitation or allowing for organic invitations is an important first decision. After you determine your core set of participants, you choose a date and location that should work well for many if not most of them. In the case of our FLOSS Manuals BookSprint for OLPC, a flurry of activity on several mailing lists initiated the desire for a BookSprint. Invitations stemmed from those who were initially interested but also from community connections already made among OLPC enthusiasts.
Location and date selection
Location and date selection go hand in hand because some locations are not going to be available for certain dates. Travel time, distance, and cost as well as visa considerations are part of balancing this equation as well. When someone needs a visa to come to the U.S. to participate in such an event, at least a month’s lead time is necessary.
Some host locations will want all participants to sign a release so that they are not liable for any unfortunate result at an unconference or BarCamp. Signing a release should be fine – nearly all this planning is happening on the good faith in others anyway, so suing when the location is typically given for free would be poor form.
Outputs
We made 7 manuals during this sprint.
Two of these became books of 120 pages (about the laptop) and 180 pages (about the operating system - sugar) each.
Since then we have remixed content into a third 'giant' 280 page book. This is the advantage of the FLOSS Manuals system - being able to recombine material in any number of ways to create new outputs. A remix was also created for distribution on the laptop itself for the roll out in December 2008 (which is ongoing) and the OLPC crew build a helper application to display the manual from within the laptop, so now all laptops come with the documentation created at the sprint. The documentation on the laptop has been taken directly from the FLOSS Manuals remix and downloaded as a zip file - a process taking about 5 minutes. Thsi zip was then included in the master version of Sugar.
Perspective from a participant
The OLPC BookSprint brought together several overlapping communities:
- hard-core, full-time participants in the OLPC, SugarLabs, and FLOSS Manuals projects
- Austin XO enthusiasts
- Austin technical writers interested in open source software
I (Janet Swisher) am in the third camp. I’ve blogged and presented on why technical writers might want to contribute to open source projects, and I work for a company that publishes some of its software as open source. I didn’t have much prior experience with OLPC, other than having bought an XO for my nephews the previous Christmas. However, I knew that OLPC was a cool project and the BookSprint was in my home town. On top of that, Anne Gentle, who I knew through the local STC chapter and as a blogging tech writer, asked me to participate. How could I not?
I walked in on day two of the sprint, having briefly seen my nephews’ XO laptop nine months before, and having downloaded the XO emulator for Windows the previous day. Lacking domain expertise, what I could contribute was technical writing expertise. My first task was to improve the style guide for the XO manual. I reorganized it a bit and added a few items that others in the room said they wanted guidance on. My opinion about style guides for open source projects is that the fewer rules writers have to remember, the better. However, this parsimony must balance against readers’ need for consistency.
After that, I reviewed chapters in the XO and Sugar manuals that were finished or nearly so, making sure they complied with the style guide, and editing anything I thought needed it. I tested procedures with one of the XO laptops that were scattered around the room. Apparently, this made an impression on David Farning, a Sugar programmer who attended the BookSprint and who later wrote: I realized this was not just a couple of programmers trying to throw together a wiki as I watched Janet Swisher intensely studying the XO’s battery. Turns out she was trying to determine if the “installing the battery” section could be misread. From my experience, a programmer would have said, “If they can’t figure out how to put the battery in, what’s the point of a fine manual?”
One factor that I did not have to worry about for the BookSprint was writing tools. The FLOSS Manuals Website, being a wiki with a WYSIWYG HTML editor, was dead simple to use. The site even kept track of which chapters were currently being edited by whom, so that we wouldn’t step on each other’s changes. There were times when a chapter that I wanted to edit was one of several that the system said was being edited by another person. Since we were sitting in the same room, I could just say “Hey, are you still working on that chapter? If not, can I break your lock?” For certain sections, I decided that the most appropriate HTML structure was a definition list, which was not supported by the WYSIWYG editor. Being familiar with HTML, I was able to switch into “code” view and insert the tags manually. However, within a few minutes of my mentioning this to Adam Hyde, he had modified the editor, and buttons for the needed tags appeared on the editor’s toolbar.
Another benefit of co-location was that when I came across a note that said, “Walter, check for accuracy,” I could just say “Hey, Walter,” and Walter Bender (founder of SugarLabs, former president of OLPC for Software and Content, and former executive director of the MIT Media Lab) would walk around the table to look over my shoulder. Talk about immediate feedback!
Bringing together communities with related interests can lead to unexpected synergies. The Sugar API documentation was not within the scope of the BookSprint, but when it came up in conversation, I was able to point the Sugar folks toward a tool for wikifying it, to encourage programmers to contribute. Also, at the Wednesday cookout, my husband, who is a musician and a graduate student, got into a long discussion about computer-generated music with Adam Hyde, who is a “sound artist” as well as the FLOSS Manuals impresario. (OK, that has nothing directly to do with the BookSprint, but it wouldn’t have happened without it!) In comparing this and other face-to-face meetings of virtual communities, I can see the following benefits:
- Community members get to know each other “for real.” If you’ve ever worked on a virtual team, you know that you work much better with team members you’ve met face-to-face. Putting faces to names and personalities to email addresses helps the team or community work together virtually in the future.
- A concrete time and place to work increases productivity tremendously. Volunteers working asynchronously tend to lack urgency; there is always some other priority that pushes the volunteer work off to “someday.” At a sprint, the work must be done here and now. And, as I mentioned, feedback can be provided within a few seconds instead of hours or days.
- The event helps put the project in perspective for participants. When a project is coordinated online, participants can get swamped by details. A sprint helps focus priorities and helps participants see how their pieces fit into the bigger puzzle.
- It’s fun! People feed off each others’ energy and excitement. Jokes are cracked, camaraderie develops, and friendships form.