Besides the Handbook on drupal.org, there is also some Drupal documentation that is embedded in the Drupal source code, and visible from the administration pages of a Drupal site. This includes help pages for modules, help text displayed at the top of administration pages, and descriptive text within administration pages (e.g. help text for a setting field).

Because embedded documentation is part of the Drupal source code, the process for helping out with writing and editing this embedded documentation is slightly more complex than for editing pages on drupal.org. Here are some ways to help out:

Test Drupal for text issues: During the development of a new Drupal version, download the new version from http://drupal.org/project/drupal, install it, and look over the help screens and user interface text. If you find something that should be fixed in a help screen or other embedded help text, file an issue: Even if you do not know how to create a patch, you can still give before/after text suggestions, and someone else can create the patch. To file an issue:

1. Log in to drupal.org
2. Create an issue via the Create Content link (http://drupal.org/node/add/project-issue)
3. Choose “Drupal” as the project
4. Choose the Drupal version. Note that it’s really only possible to change user interface text, help text, and other explanations in the version of Drupal that is under development. Stable releases have been translated into other languages, so their user interface text is almost never changed.
5. Choose component “documentation” if the issue is in a help screen, or “user interface text” if it is user interface text, or choose the module that the issue pertains to as the component.
6. Tag the issue with “ui-text” or “Help text” as appropriate.
7. Choose category “bug report” — text being wrong, missing, or unclear is a bug, not a feature request or task.
8. Make up a clear title and description, and submit your issue.

Help with existing issues: Use the advanced search for issues in the Drupal project (http://drupal.org/project/issues/search/drupal), and look for component “documentation” or “user interface text”, or search for tags “Help text” or “ui-text”. Be aware that most of the issues filed under component “documentation” are issues with the in-line programmer API documentation of functions in the source code (displayed on api.drupal.org), so if you are not a programmer, these will not be things you will probably want to work on. Even if you cannot write patches, you can still review patches and make suggestions on how to improve text, by commenting on issues. Some tips on using the issue queue:

• 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).
• Even if you are not a programmer, you can still review patches. Find an issue that has status “needs review”, scroll down to the bottom of the issue’s comments, and find the latest patch attachment. Click on the attachment to see it. The lines with + are being added, lines with – are being removed. Some patches will also have a screen shot, making reviewing even easier.
• If you think a patch is good, add a comment saying what part you reviewed and that you thought it was good. If you think your review was comprehensive, or if several people have commented that it’s a good patch and you think the coverage overall is comprehensive enough, change the issue’s status to “Reviewed and tested by the community” (also known as “RTBC”).
• If you think a patch needs some work, change the status of the issue to “needs work”, and add a specific comment about what you think should be changed (if possible, with a suggestion of what to change it to). Please try to be constructive.
• If the issue you are looking at doesn’t yet have a patch, you can either make one or add suggestions as to what the text should say (someone else can read your suggestions and make a patch). If you attach a patch file, be sure to change the status of the issue to “needs review” so others can test and review your patch.
• 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).