ARCHIVE - Drupal Core Documentation Sprints

Last updated June 21, 2011. Created by jhodgdon on August 5, 2009.
Edited by esmerel. Log in to edit this page.

This page has been archived. If you are looking for information on organizing a sprint, check http://drupal.org/node/424194
-----

In conjunction with the upcoming release of Drupal 7, we are holding some "Documentation in Core" sprints -- check the list of sprints on the Documentation group page for a schedule of upcoming events. Or, if that hasn't been updated, here are some scheduled sprints:

• User interface text review sprints: see http://drupal.org/node/672772

At the time of a sprint, everyone who wants to join should log on to the IRC channel "#drupal-docs" on Freenode (see the Getting Set Up section below for more information on IRC).

Purpose of the "Documentation in Core" sprints

The main purpose of these sprints is to make sure that the documentation included in the core distribution of Drupal is issue-free. This includes:

• Function and API documentation - documentation for programmers for Drupal core and modules, which you can see on http://api.drupal.org
• Update guides - documentation for theme and module developers on how to update their themes and modules from Drupal 6 to Drupal 7. These are found at http://drupal.org/update/modules/6/7 and http://drupal.org/update/theme/6/7 -- basically, both are lists of changes in Drupal's core functionality that affect module and theme developers (with links to the issue that introduced the changes).
• User interface text (e.g. field labels and help text on administrative screens) and help pages (the documentation you get when you click on a "for more help click here" link) within the core Drupal distribution.
• Installation guides and README files - included in .txt files in the Drupal distribution.

If you are interested in making all of these parts of the Drupal ecosystem better, the following sections have some suggestions on how to participate.

General issue queue suggestions

• Look for issues whose status is "active" or "needs work" if you want to write some documentation or code. Look for "needs review" issues if you want to review what others have done (an excellent place to start if you are new to Drupal issues, and a vitally important part of the process).
• Issues on Drupal 7.x are a priority over issues on Drupal 6.x. Bug reports are a priority over feature requests. Critical issues are a priority over normal issues, which are a priority over minor issues.
• When you find an "active" or "needs work" issue that you want to work on, assign it to yourself before starting, so others will know you are working on it. Don't decide to take on an issue that someone else is actively working on (unless it has been several weeks with no activity).
• 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.
• If you are able to make a patch for the issue, attach it to a comment, and mark the issue status "needs review".
• If you find an issue that appears already to be fixed due to prior checked-in changes, you can mark it "fixed". It will remain visible and "open" for two weeks, so if others do not agree with you, they can always re-open the issue.
• If you are reviewing an issue, and find problems with the patch someone else had created, explain what the problems are, and mark the issue "needs work".
• If you are reviewing an issue and think the patch is great, mark it "reviewed and tested by the community" with a short comment about what aspects of the patch you reviewed. But if you don't feel your review was comprehensive, you can just leave your comments and leave it in "needs review" status.
• If you assigned the issue to yourself, and are done working on it, un-assign so everyone will know you no longer plan to work on it.
• And above all: Don't take anything in the issue queue personally! The intent of the issue queue is to provide a forum for discussion on how to make Drupal better, so try to take any comments on your patches as constructive comments and thoughtful discussion (even if not everyone writes their comments in this way).

Which issue queues to search

• If you are a programmer who can also write documentation, check the queue of issues in Drupal in the "documentation" component. This is almost entirely composed of issues where someone has noticed that there is a problem with some function/API documentation.
• Anyone can look through the queue of issues in Drupal tagged with "Needs Documentation". This contains issues where someone has modified the core PHP files of Drupal, and the result is that some documentation also needs to be updated. Sometimes it is API function documentation for programmers, or "update guides" for programmers that are needed. But sometimes it is help documentation (something you would see when you click a Help link from a Drupal site's admin screens), so you might find something you can work on in this queue.
• Anyone can look through the queue of issues in Drupal tagged with "ui-text", and the queue of issues in Drupal in the "user interface text" component. These contain issues where some user interface text needs an update.
• Anyone can look through the queue of issues in Drupal tagged with "Help text". This contains issues where some help screen text needs an update.
• Or, you can always just go to the usual Documentation issue queue and not work on "core doc" issues. Just because you are at a "core doc" sprint doesn't mean you can't work on something else, and/or use IRC to chat about it.
• If writing in English is not a strong skill of yours, please consider reviewing documentation rather than writing it, or if you can write well in another language, maybe you would like to help out by translating Drupal or its documentation? See http://drupal.org/node/17229 for information on translating documentation, and http://drupal.org/contribute/translations for information about translating the user interface in Drupal.

Further reading, Getting set up, Background

• The Contribute to documentation section is the best starting point for learning how to get involved in improving Drupal documentation.
• Within the Contributing section, the pages on Editing documentation embedded into Drupal and Updating API documentation have more details on these two tasks, including how to create and review issues and patches, set up your development environment, style guidelines, etc.
• Also within the Contributing section, the Documentation team page tells how to communicate with the documentation team, including IRC information.