I have finally finished my formal grant proposal to the Knight Foundation to fund documentation sprints for Drupal. (You can read the original community proposal on the Knight Drupal Initiative group page.) The basic idea is that there is a lot of work to be done and getting people together throughout the year, around the world, would accelerate the documentation work needed to really make Drupal more accessible to people. The Drupal community has had various code-related sprints for a while: code sprinting at DrupalCons, search sprint, testing sprint, etc. Earlier this year I slapped together an impromptu documentation sprint at DrupalCon Boston because, well, it just sounded like a good idea to gather interested people to focus on an often neglected aspect of not just Drupal, but open source projects generally. Spurred by the good things that were accomplished there (like the new Getting Involved guide) I pulled another sprint together in DrupalCon Szeged that was a little more organized. Other than the camaraderie and tons of work we got done, it really hit me how important the sprints were in other ways too. It occurred to me in Hungary that sprints are a very valuable tool that isn’t really being utilized by our community and I wanted to make it a goal to figure out how to do that. So, I’ve been planning more sprints, some online in IRC, others in my local Drupal groups. As I go, the things I am learning make me even more convinced that this is a great tool at our disposal, if we can just harness and organize it.
Take my hand
One of the biggest benefits to sprints that I have seen is that it lets people working on documentation for a massive project with hundreds of thousands of people feel like it is a lot more approachable. Drupal, as a project and a community, can be very overwhelming. It is great to give people the ability to edit and take part in the process and we’ve been working to improve the initial “what do I do now?” documentation for people who would like to help. But, at the end of the day, there is nothing like having someone actually talk to you, take you by the hand if necessary, and really make you feel comfortable with the beast. Many people who have attended sprints so far want to help but don’t feel confident to dig in, or they have been helping but feel undirected and uncertain. The common path in open source is to open up the code, docs and process to whoever wants to be a part and then let them “scratch their own itch.” As a philosophy it trends towards the “here it is, knock yourself out” mentality. That’s not so bad for self-starters and people that don’t mind testing boundaries, but for many, many people it is just plain frightening. Gathering people at sprints is a way to get the “mentors” and the “learners” in the same space with the specific goal of collaboration. That leads to a lot of open questions with assuring answers, joint puzzling, “let me show you how, real quick” and overall confidence-building. It means that work gets done but you also have a group of people that feel more confident to move forward out of the sprint environment.
Being there
In our information age and world-wide communication, it seems like it would make sense to just get everyone online and bang things out. That definitely works, but the more I work in a large, world-wide community and conduct both physical and virtual sprints, I am finding that shared physical proximity and the lack of distraction that helps engender has a huge impact on the amount and quality of work. This may surprise some, but I really don’t think it should. We are human beings after all. You know, social mammals. Online communication allows for a lot of things that wouldn’t happen at all otherwise and is certainly not a tool to be spurned, but people communicating face-to-face has its own deep-rooted advantages that our cybertools have not yet replicated, especially when you are in the low-fi text world where most of us spend our online existence.
I find running virtual sprints more exhausting and definitely harder to sustain over long periods. Hammering out issues and helping people find their way is much more efficient and comfortable when you are sitting next to each other. There are a couple of obvious (I think) reasons for this:
- Talking is faster than typing for most people. Even if you have great speed, keeping that pace of information flow by manually typing is hard to sustain over long periods.
- Sitting in the same place brings focus. If I’m in a meeting room with 10 other people, my focus doesn’t tend to stray to the laundry or TV sitting in the corner. Online, I personally find myself all over the place, while in a room of people I’m really aware of them.
- Shared experience provides conversational queues. This is the classic difference between the amount of focus you must have when driving and on the phone with someone versus driving and talking with a passenger. When the other person is sharing the environment and experience, your conversation will naturally take that into account. It may seem small, but especially over hours of working together, it can be exhausting.
- Body language is a huge part of human communication. I think most people get this one.
Who can we learn from?
I started sprints simply following the lead of the loosely organized code sprints from DrupalCon. I’ve been learning as I go about how to make them more effective. We can’t be the only open source project that has thought of this and so I’ve begun checking out what others are doing or have done. My research is just beginning and while I’ve definitely studied and talked with other open source docs teams, I haven’t actually encountered a lot in the way of sprinting specifically.
Plone has done some work in this area, coming up regularly in Google searches. I’ve been going through their planning and wrap-up docs for some past sprints.
A friend recently sent me an link related to the very cool Floss Manuals project. Several of the books on Floss Manuals were created through book sprints, where a group of knowledgeable people got together, split up the content and just wrote the books. While this is geared at “publishable” discrete books, this is the same concept as documentation sprints; sit a bunch of people down in the same room, work things out and then just. do. it.
So, what other resources do people know of specifically for documentation sprinting? Even good sprinting advice generally would be welcome too. Thoughts and ideas are welcome. We all move Drupal forward.
RockTreeSky 