Doc sprints

This is a guide to organizing a documentation sprint. It contains advice and tips from people who have organized doc sprints, to help you in organizing one, too. This guide also draws on ideas from the FLOSS Manuals Book Sprints book.

What is a doc sprint?

A doc sprint is a short period when a group of people come together, virtually or actually, to collaborate on writing documentation on a given topic or related topics.

Types of sprints

Sprints can be virtual or in-person, or some combination. For a virtual sprint, everyone participates from wherever they happen to be located, communicating solely through mediated channels. For an in-person sprint, participants gather in the same location for the duration of the sprint, so that they can communicate face-to-face. Hybrid sprints can be mostly-in-person with some remote participants, or mostly-virtual with some local gatherings. In-person sprints require more logistical planning, to secure a meeting location, to get everybody there, and to house and feed them during the sprint.

Another way to categorize sprints is by topical focus. For example, a sprint might focus on a particular subject area, such as Web development, or translation into a particular language.

Planning a sprint

Determine the goals

Have a clear idea of what the goals are for the sprint, for both content and community. This helps drive your planning of lower-level details.

• Do you want to document a particular topic area?
• Do you want to create a particular type of documents or resources? For example, tutorials, code examples, or translations in a particular language.
• Do you want to attract new people to contribute to MDN?
• Do you want to increase cohesion among existing community members?

Decide the type and scope

Based on your goals, decide on the type of sprint (virtual, in-person, or combination) and the scope (what participants will focus on).

For example, if you want to attract new community members, a local in-person sprint would be a good choice, because no travel is involved, but participants get to meet each other. If you want to focus on a specific subject area, where the content contributors are geographically distributed, and already know each other, then a virtual sprint may make sense.

Pick dates and times

For in-person sprints that require travel, we've found that three days (such as two weekend days and a weekday) is enough time to get some significant work done, without taking too much time away from everyone's normal lives. For public, local, in-person sprints, one day is the most you can expect most people to commit. For virtual sprints, we typically run for two days: a weekday and a weekend day. As an alternative example, in the past there has been mini-sprint for writing and translating docs, every Wednesday evening in the Mozilla Paris office; it was primarily in-person for locals, but also got remote participation from Montreal (where it was at lunch time).

Attaching a sprint to the end of a conference that everyone attended worked well; trying to run a sprint during a conference that everyone attended did not work so well. Make sure that participants know about the sprint when they make their conference plans, so that they allow extra days for the sprint.

Consider the time zones that virtual participants are in; be sure that you allow enough working time in each time zone, and have some overlap when multiple zones (such as Europe and Americas, or Americas and Asia) are awake. However, it's just reality that no one time is good for everyone everywhere.

For virtual sprints, the dates can be set as little as 2-3 weeks in advance. For in-person sprints, you need to decide further in advance, in order to allow time for people to decide and make travel arrangements.

Promote the sprint

You can make the sprint open, and invite the world, but you should have a few key people that you know for sure will participate. Work with them when selecting dates, to ensure that they are available during the chosen dates. If the sprint is not open, then you need only extend invitations; make sure that each invitation is personal, explaining why that person has been specificallly invited.

For public sprints, identify existing groups that have an interest in the topic, for example: local Web developer meetup groups for a local in-person sprint. Send an announcement through whatever channel is appropriate for that group. Be sure to provide a link to a web page with more details, and include a call-to-action for people to sign up for the sprint. Eventbrite and Lanyrd are two services that support sign-ups. For Mozilla developer events, we have found that about half the people who sign up actually show up.

Use the social media channels that are appropriate to reach your target attendees. We have found that for Web developers, this means Twitter, followed by Google Plus, more than Facebook or LinkedIn. However, popular channels can vary geographically (such as Orkut in Brazil). Reach out to a few well-connected people who have a large following among your target audience, and ask them to re-share your posts.

Logistics for in-person sprints

Logistics for in-person sprints are greater for longer sprints and those where sprinters travel to attend. A short or locals-only sprint need relatively little logistical support.

Budget and funding

You need to figure out how much the event is going to cost, and where the money is going to come from.

Costs to consider in your budget include:

• Travel
• Lodging
• Food
• Meeting space

Some of these costs can be self-funded by participants, meaning that they pay for their own costs. There are a variety of ways to save money, which are mentioned in the following sections.

It may be possible to get sponsorship from Mozilla to fund some of the costs of your event. It helps to have a clear focus for your event, and a specific plan and budget. If there is a Mozilla Rep in your area, work with them to request budget and swag through the Reps program. Otherwise, you can submit a developer events request in Bugzilla.

Venue

There are lots of options for meeting space. If you are in a city with a Mozilla office, you can use the community space in that office. Elsewhere, options include meeting rooms in libraries, churches, coffee shops, or businesses where you have contacts. Many cities now have coworking spaces that rent their conference rooms for a reasonable fee.

Resources

Be sure that your venue has good chairs and tables, and reliable power and Internet access. Sitting all day on a bad chair is not just uncomfortable; it can lead to injury. Make sure that the number of sprinters and their computers and devices does not overwhelm the power supply and available Internet bandwidth. Be generous (but not dangerous) with extension cords, and if necessary, international plug adapters. A projector for shared viewing can be very helpful. Whiteboards and sticky notes are great for brainstorming and planning.

Travel

Travel is relevant only if the sprinters do not all live close to the sprint venue. The usual strategies for saving on travel apply, and are not specific to doc sprints.

Accommodations

Where sprinters stay should not be inconveniently far from the meeting venue. It can be cheaper (and possibly more fun) to split the cost of a vacation house or flat, rather than paying for individual hotel rooms. If you have a mix of visitors and (willing) locals, the visitors can stay in the homes of local community members.

Food

Sprinters need to eat! Make arrangements for food during the sprint, and inform sprinters if certain meals will not be arranged. If the group is staying in a home, you can save money by buying and cooking food rather than going out to eat. Even if food is self-funded, it can reduce hassle to pitch into a common fund for food, rather than splitting every restaurant bill. If your venue allows, have snacks (some healthy and some not) available between meals.

Fun

Make time for non-writing social activities. These can be informal, like going for a hike together, or more formal, like a tourist excursion. Going out for beer (at the end of the day, of course) is usually a winner. On the other hand, don't plan every hour of every day. Everybody needs some down time, especially introverts.

During the sprint

Planning the work

Tracking tasks

Have a way to track what tasks need to be worked on, who is doing what, and what has been completed. For MDN doc sprints, we use a wiki page for advance planning, and an etherpad for tracking work during the sprint.

Often, people want to help but don't know where to start, and deciding among many options takes too much mental effort. For any given participant, give them a couple of possible tasks ("you could do A, or B"); this simplifies their choice, without making them feel like they're being bossed around.

Collaborating

One of the benefits of in-person sprints is that people can work together in ways that they might not be able to when they're not in the same place, for example, by working out ideas together on a whiteboard or by brainstorming with sticky notes. Still, there are opportunities for collaboration and camaraderie in any type of sprint. Chatting via IRC is essential for virtual sprints, and still very helpful for in-person sprints (for example, for sharing links). For a greater sense of "virtual presence", consider using a video conferencing service, such as Google Hangout.

As an organizer, look for common interests among the participants and for ways that they can work together.

Celebrating accomplishments

Be sure to take time to celebrate accomplishments at the end of the sprint. This gives participants a better feeling than when the sprint just ends without any summary. If possible, have people "demo" what they have done, even if it is just showing a new article page.

Also, share the sprint accomplishments via a blog post, to celebrate publicly as well. This is important for any kind of sprint, but especially for virtual sprints, where the participants might not all be online at the official end of the sprint for a wrap-up session.