I've never organized or taken part in a hackfest event but am curious if people have tips/ideas for organizing such an event that's specific to writing documentation. I've been on the sidelines for a few testfest events (writing unit tests) but they're pretty straight forward especially when compared to writing good documentation. My main worry is dealing with quality control while teaching people how to improve.
- How do people feel about creating a "HOWTO organize a DocFest" here?
- How did the Documentation Sprints on Day #1 of the conference go?
- All information and tips are welcome
Book Sprint manual on FLOSSManuals
Conveniently, the FLOSS Manuals project has just published its manual on running Book Sprints: http://en.flossmanuals.net/booksprints
This site would certainly be an appropriate place to talk about various approaches, since the FLOSS Manuals model is just one option.
Whatever the time frame of the effort, I think it's very important to have a tangible goal that you can measure and celebrate achieving. It's really cool, at the end of a FM book sprint, to go to lulu and order the book I just helped write. If you're not producing a book, you should still find a way to say "Yay! We did it!" at the end.
Quality is not as big an issue as you might think. People who really suck at writing will tend to self-select away from writing. Even if the uber-programmer on your project can't write their way out of a paper bag, it can be extremely helpful to have them present at the event as a resource for those who are doing the writing. I was concerned going into the Intro to the Command Line sprint that the hardcore FSF geeks who were invited to participate might not be able to write accessibly for newbies. But they were given examples to set the tone, and with a few exceptions, they did amazingly well.
Still, it helps to have one or two people tasked with reviewing everything to ensure quality and consistency. While such people may also self-select, have at least one editor lined up in advance.
I'm not sure that you can really do much to help people improve over the course of a short sprint, when you are focused on getting a goal achieved. However, a topic that came up at WOSCON that we want to continue discussing was how to mentor people over the longer term.
I think the doc sprint day at WOSCON was extremely productive for the Gnome team, not so much in producing text as in stepping back and rethinking their whole approach to documentation. The Drupal folks did a "convert writingopensource.com to a community site" sprint rather than a documentation sprint. I think that has also turned out nicely :-)
Gnome Doc Sprint
Indeed, the doc sprint for Gnome was amazing. My guys are still running. ;)
We were venturing into new territory, so for us it was really helpful to be able to have face-to-face conversations and to brainstorm together. Lynda was loads of help in leading us through a content planning session.
I'm not sure I have great guidelines yet. Ask me again after we've done a few more. I would recommend having a clear goal in mind, and having a coordinator to make sure you're always working toward that goal. And as with any writing, you need to spend time planning. Don't just jump right into putting words on paper.