Communications from DMN

As you may or may not know, I helped organize a two-day FLOSS Manuals book sprint at this year’s Toronto Open Source Week (held at Seneca College).

If you’re not familiar with a book sprint, read this for details.

This book sprint came about because:

1. For the last two years, I’ve been promising Adam Hyde (head honcho of the FLOSS Manuals project) that I’d take a more active part in a book sprint
2. I thought that this would be an interesting event to hold at Toronto Open Source Week

This time around, the goal was to complete a manual for the Mozilla Thunderbird email client. I hosted the book sprint in Toronto, and Adam Hyde took overall control from Berlin (where he lives).

It was an interesting two days, to say the least. Here’s a summary of what went down.

Rallying the troops

In the weeks leading up to the sprint, I worked with Adam Hyde and some people from Mozilla to nail down what needed to be done. I also co-ordinated with Beth Agnew, the co-ordinator of Seneca College’s Technical Communication program, to find the students I mentioned earlier and brief them on the sprint.

Why students? I thought it would be 1) a good opportunity to for them to get some real-world experience, and 2) to have something resembling an actual writing credit when they went for interviews for co-op positions. Involvement in a book sprint would show a potential co-op employer their initiative and that they were interested in things tech comm.

The sprint gathered a mix of participants. In the end, seven students from Seneca College’s Technical Communication program joined. A graduate of the program, who’s also former co-worker of mine, managed to make it to day one. A developer who emailed me about the sprint also joined in. To be honest, I was surprised to see him – he emailed me once and I never heard from him again until the day of the sprint!

Blake Winton, a developer from the Mozilla Messaging team in Toronto, was on hand the second day to answer all of our questions. Several people from the Mozilla Messaging Team in Vancouver also took part remotely. Their input and insights were invaluable.

In all, around 20 people were involved either on site or remotely. Not everyone was writing. A number of people were editing and proofreading the book, too. That’s pretty impressive.

[A quick aside: I’d like to thank: Chris Tyler, one of the organizers of Toronto Open Source Week and of FSOSS, for generously arranging space and equipment for the sprint; Beth Agnew, who co-ordinates Seneca’s Technical Communication program, for helping find student who were interested in taking part in the sprint; everyone who took part in the sprint, both in person and remotely; and everyone from Mozilla for offering support and pitching in.]

Getting down to work

The manual was started by a technical writer with Mozilla Messaging named Jennifer Zickerman. We weren’t starting from scratch, but there was still a lot to do.

Here’s a good chuckle: when I was driving to Seneca College on the first day, a commercial came on the radio promoting a condominium development. The name of the development? Thunderbird. I thought that had to be a good sign …

Even so, the first day of the sprint started off a bit slowly. There were three of us on site, and it took us an hour or two to get our footing. On top of that, a bulk of our team, consisting of the students, would be coming in later because they were attending a special seminar that morning.

Once everyone started filtering in, a lot of writing started getting done. It was around that time that the folks in Vancouver were coming online so that really helped.

Adam Hyde was constantly spamming me with helpful advice and hints via email, and we were using the IRC client built into the FLOSS Manuals editing interface to communicate with everyone working remotely. On site, there was a lot of back-and-forth among the participants – questions, ideas, comments, and bad jokes. OK, the jokes were mine …

One of the participant was wearing a t-shirt emblazoned with RTFM. We came up with a new meaning for that acronym: Read The FLOSS Manual.

The goal for day one was to have 80% of the content finished. That’s what happened, more or less. Not a bad day’s work.

Day two started off in pretty much the same way as day one. Three of us got to work at around 8:00 a.m., and the rest of the team started filtering in an hour or two later. Since the previous evening, a couple of new chapters were added and some of the people working remotely added a lot of content.

The goal for day two was to complete the last 20% of the content, then do editing and cleanup. We were supposed to down tools at 1:00 p.m. but I let that slide by half an hour or so. No one tell Adam Hyde, please!

We got to the editing and cleanup phase, with everyone taking a look at chapters and sections that they didn’t work on. Editing and cleanup can be as difficult as writing, but it’s also very rewarding. And very necessary. Rewarding in that you can really see the final product taking shape. Necessary because you catch all the silly (and not so silly) errors that slip in when you’re writing in a hurry. Things like doubled words, missing punctuation, and glaring spelling mistakes.

In the end, the teams wound up writing 14,000 words over the two days. That translated into about 135 pages. Not too shabby.

A few thoughts about the sprint

It was fun. But ..

At the end of the first day, my thought was How does Adam Hyde do this without going crazy? Running a sprint isn’t easy. Thankfully, I wasn’t doing it alone. And I now understand why I avoided the management path during my corporate career.

What’s interesting is that I threw everyone into a situation that many professional technical writers would have trouble coping with: getting used to a new tool, writing about unfamiliar software, and rapidly writing in a collaborative environment with a very tight deadline. I have to say that everyone coped admirably.

When I interviewed Adam Hyde for our podcast a couple of years ago, he mentioned that during a sprint it’s hard to get people to stop working if they’re enjoying themselves. A few times over both days I called for a break. No one listened to me; they all kept typing away.

When you’re writing online, it’s hard to know how much progress you’re making. You don’t see a page count or a word count. Just seemingly endless lines of text and images. So every few hours, I published a PDF version of the manual and let everyone know how many pages we had. That can be a great motivator – for example, that we had 95 pages at noon and 115 pages at 2:00 p.m. shows actual progress.

We ran into a few glitches. There was occasional trouble with the wireless Internet connection at the college; that’s to be expected with a network being used by a large number of people. And at one point on the first day, the FLOSS Manuals server stalled. It turns out that the site was being hit by a lot of people. We were dead in the water for about 45 minutes, which was a bit frustrating.

I wasn’t able to get across to the participants that they needed to write quickly, that they didn’t need to worry about making things perfect the first time around. Writers are like that; we try to write everything perfectly the first time. In a situation like this, quantity trumps quality.

I’ll let you in on a little secret: the key to good writing is editing. Obviously, I wasn’t able to make that clear to everyone either.

Overall, I think we did a good job. Could things have been better? Sure. Could they have been worse? Definitely. But in the end, we achieved the goal. All that’s left now is some fine tuning.

Everyone who took part in the book sprint can and should be proud of what they did. Every contribution, no matter how small, made a difference.