[FM Discuss] hats off to scott nesbitt
adam at flossmanuals.net
Tue Nov 15 01:46:53 PST 2011
I just wanted to quickly highlight the amazing work Scott is doing with
these 1 day update sprints. Scott wrote a great blog post about it (see
below) and from this I wonder about a couple of things immediately:
* can we turn this into a template for FM 1 day events?
* can FM ORG (the foundation which is the base from which all the lang
sites jump off) could put a small amount of $ towards making these
events happen. Perhaps something like 100 euro for tea and biscuits etc
per event and also back it up with some PR from Camille...
What do you guys think?
This is what he wrote about it:
In this case, the sprint was to update the manual for Thunderbird. There
were a number of changes to the software in the year or so since I was
involved in writing the original manual. But due to a number of
constraints — both personal and professional — I could only devote one
day to the sprint.
Obviously, there was a bit of planning involved. I gathered together a
group of participants (mostly in Toronto), found a venue, and working
with the folks at Mozilla (who created Thunderbird) came up with a list
of changes that needed to be made. That involved pinpointing the
relevant changes and making a list.
Afterwards, I was mulling what made the sprint successful. Part of it
was the planning. The process that I used was very helpful. And you can
apply it to any group writing project.
Let’s take a closer look at what I did and how it worked.
Don’t just jump in
It’s easy enough to jump in and let the people involved in a project
figure things out for themselves. Sometimes, that results in some very
But it’s not always the most efficient way to proceed. And efficiency is
something that’s important when you’re working with a group and are,
especially, when you’re on a tight deadline.
For the sprint, I created a page on my wiki that listed:
What needed to be added or changed
Whether that content was new or an update
Who was working on it
Here’s what the list looked like:
A sample list of topics
Obviously, I didn’t add details for the last point in that list until
the day of the sprint. I also let people choose what they wanted to work
on. Doing that helped keep the participants happy.
Going beyond a sprint
Not all collaborative writing projects are as intense as a book sprint.
But you can use the framework I just described for any collaborative
If you’re starting from scratch, you can use your outline to build your
list. How granular you go will depend on what you’re writing and, of
course, how detailed you make your outline. My rule of thumb is to keep
things to a second or third level heading at most.
Always remember, though, that your list is fluid. You and your
collaborators might find yourselves adding, removing, or changing things
on the fly.
Remember when I mentioned that I let the participants in the sprint I
ran choose what they wanted to write? That helped motivate them — they
found something that interested them, which made them more enthusiastic
about what they were writing. However, if you run into conflicts then
it’s up to you (or whoever’s running the project) to step in and have
the final word.
If I could do anything differently, I would have added a column that
listed the status of each item of work. The statuses would include:
Planning is a key component of any writing project. When you’re
collaborating with others, even just one other person, planning is even
more essential. Having a plan keeps everyone focused. I’ve found that
focus helps get the work done faster and more efficiently.
Founder, FLOSS Manuals
Project Manager, Booki
Book Sprint Facilitator
mobile :+ 49 177 4935122
identi.ca : @eset
booki.flossmanuals.net : @adam
More information about the Discuss