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.
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:
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.
This forms the topic of the bulk of this book. Although we provide as much guidance as we can, you should recognize that:
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.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.