• INTRODUCTION
• INTRODUCTION
• PHILOSOPHY
• THE AIMS
• THE PROCESS
• COMMUNITIES
• PLANNING
• THE PLAN
• MAIN ISSUES
• ROLES
• TIMELINE
• BUDGET
• VENUE
• TOOLS
• REMOTE CONTRIBUTIONS
• TIPS & EXPERIENCES
• ANNES TIPS
• ADAMS TIPS
• CASE STUDIES
• INKSCAPE
• XO / SUGAR
• FLOSSIFY ONE
• COMMAND LINE
• CIVICRM
• OTT
• APPENDICES
• CREDITS

The Process

A book sprint is a surprisingly light-weight process. Part of this stems from the use of the FLOSS Manuals platform. The FLOSS Manuals website allows us to build a book sprint around it with very little overhead, letting people concentrate on the important tasks--notably the actual writing. However, providing the technology isn't the entire story. Book Sprints are an evolving Social Methodology, and the FLOSS Manuals website is the best platform for using in this context.

What should be acknowledged however, is that the FLOSS Manuals platform is at the time of writing, only committed to manuals about free software. The platform is really key, as it makes the process easy, fast, and collaborative. Previous sprints done without this platform have battled with their tools whereas we have a very good platform which helps the process. The FLOSS Manuals foundation is currently working on the development of a new content-agnostic collaborative writing and book sprint platform. Stay tuned.

Obtaining a Commitment

First, someone has to decide that there needs to a Book Sprint on a particular subject.

At this point the  project leader/initiator needs to decide:

• Can you use the FLOSS Manuals system (it can only be used for documenting Free Software)?
  
• Is the outcome worth the commitment? A book sprint usually produces a text of about 160 to 250 pages. This is not enough to fully cover some project's documentation needs. In some cases the leaders of the project must be prepared to choose a narrow topic during the pre-planning phase and avoid 'mission creep'. They must agree to feel satisfied by the outcome of the sprint.
• Who will participate, and who will take responsibility? If the project has certain recognized leaders (who may or may not hold official positions) their moral support is very useful for a project like this one. Support from such leaders will ensure that other people will take the project seriously and make the time to participate. However, you can also choose to document a software where their is no involvement from any of the 'official' team. Any one can choose to write documentation, and there is not enough of it in the world - why limit who can do it?
  
• How much time and money can be committed? Costs can be kept low in a variety of ways, but the organization should be prepared to spend some money.
• Who can maintain the document? It's demoralizing to produce a great book and have it become useless after a year or so because no one keeps it up to date.
  

Pre-planning

This takes two to six weeks. It usually involves a few people intensively (sometimes up to about 10 people) but can also draw in ideas from a larger community.

The sprint

This forms the topic of the bulk of this book. Although we provide as much guidance as we can, you should recognize that:

• Each sprint is unique. A leader needs enormous flexibility, along with the ability to listen to participants and find quick solutions.
• Book sprints are still at a young stage. Although they have all been considered successes, we are always experimenting with ways to make them better.
• You never really know what a people-based process is like until you've done it--and perhaps done it a few times.
  
• Maintaining a positive atmosphere and letting people go home feeling good is more important than doing it "right." Be happy with whatever outcome you get--it is very likely to be better than anyone expected anyway!
  

Post-sprint tasks

Although a sprint is not the chaotic, slapdash effort many people would imagine, the resulting book can always be improved. There might be gaps, as well as redundant material written by two different people who did not realize they were duplicating each other's work. The book might have inconsistencies in terminology, style, and point of view that should be harmonized to make it flow better. And sometimes sections need to be rearranged.

If this occurs then usually the participants of the sprint have the energy to make these fixes in the week or two following the sprint, and their enthusiasm should be harnessed to do this.

Over the long term, the project should appoint a maintainer who checks the book every couple months to see whether something is out of date or whether it would be useful to add new material. This maintainer can draw on sprint participants and others to add material. At some point, it may be worth undertaking a major revision in a new sprint. For example, the first edition of the CiviCRM manual was written at a sprint in 2009, and the second edition at a sprint in 2010.