Last updated 13 August 2014.

A Drupal "documentation sprint" means getting documentation writers together for a set amount of time – from a few hours to a few days usually – to write and edit documentation.

See the main organizing sprints page for generic information on how to organize a sprint; this page has information specific to Documentation sprints.

Who can participate?

Everyone! A documentation sprint does not need to be run or attended by only experienced contributors to Drupal documentation. Anyone with a desire to help make Drupal documentation better can take part, as long as the sprint is organized with tasks for all experience levels (see below).

How do I find a sprint to join?

You can find a list of sprints taking place around the world on the Documentation group page on, or by searching the event page for a sprint. Keep in mind that even if you can't get to a sprint in person, you may be able to join in on-line -- contact the organizers or post a comment on the event page to find out for sure.

If you don't find a sprint to join, you can organize your own! (See below.)


Helpful skills and knowledge for sprint coordinators:

  • Comfortable with the Docs issue queue (can lead others in issue browsing/searching, tags, posting, and commenting).
  • Comfortable with the Documentation management page (can lead others in using it to find a page to work on).
  • Familiar with the style guidelines.

Background and orientation

The following background information should be useful for orienting documentation contributors at your sprint:

  • Contribute to Documentation pages - the main starting point for any new Documentation contributor.
  • Guide to Drupal IRC
  • Documentation policies, guidelines, and standards
  • Contributors may want to add the Documentation Team Links block to their Dashboard. To do this, click on Your Dashboard in the top navigation, and click on "add block".
  • Participants may need to set up a local web server, in order to install local test Drupal sites to review documentation, or to test changes to Drupal core user interface text. People working on patches to Drupal core (API docs or user interface text) will also need to learn about the Git version control system, and all contributors may need a text editor or other development tools.
  • If there's a chance that multiple people might be working on the same page or issue, follow this procedure:
    1. If you are starting to edit a page, put the following at the top: "This page is currently being edited by [your name]", and save the page. Make sure you remove that text when you are done.
    2. If you are unsure of your changes on a page, file an issue when you are done, asking for a review.
    3. If you are starting to work on an issue, begin by adding a comment stating what you plan to do, and assign the issue to yourself. When you are finished, go back to the issue and comment again about what you did, change the issue status to "needs review" or "fixed" if appropriate, and un-assign the issue.
    4. Anything pertinent to the issue that you discover or think of, be sure to put it in a comment on the issue so no one has to go through the same thought process again. Please try to provide constructive criticism rather than writing statements that seem more like personal attacks.
  • Especially if there are any connectivity issues at the sprint, it's advisable to do most of your editing in an external text editor (such as NotePad or an email program). From that source, update the site occasionally.

Finding tasks for your sprint

The following ideas may help you to find tasks appropriate to your sprint:

Other considerations for finding tasks

  • Look for issues whose status is "active" or "needs work" if you want to find writing tasks. Look for "needs review" issues if you want reviewing tasks (an excellent place for new contributors to start, and a vitally important part of the process).
  • Tasks related to the latest in-development version of Drupal are a priority over issues on older versions. Bug reports are a priority over feature requests. Critical issues are a priority over normal issues, which are a priority over minor issues.
  • If you will have some people at your sprint that are not strong writers of English, you might suggest that they do technical reviews rather than writing tasks.