Best Practices
Documentation
Since you've decided that your project is worthy of releasing to the Drupal community for general use, it is a good idea to put some thought into documenting your project. There are several forms project documentation can take; your project should include several of them:
- README.txt - This will be included with your project's distribution (tarball). It should include a short description of what your project does, and provide further information to the person who is installing your project. It should include any special instructions or considerations that need to be addressed at installation or configuration time.
Example - INSTALL.txt - This is an optional file that can be used if the "readme" file is too large or complex. It would concentrate on the installation tasks.
Example - Project page - This is a succinct description of your project. The first paragraph or two should be a short description of your module, theme, or installation profile's basic functionality and why people would want to use it. After that short description, insert the teaser end tag ("<!--break-->") or click on "Split summary at cursor", to define the "teaser" that will be shown when people are searching for modules, themes, etc. The rest of your page can include more details of what your module does, what your theme looks like, your project's dependencies, related modules, what makes your module/theme/profile different from other similar ones, compatibilty concerns, links to demo and documentation pages, who sponsored the development, etc. But you don't have to have a complete installation and usage guide on this page -- that is better done in the README or a Handbook page.
Example - CHANGELOG.txt - This file will be included with your project's distribution. It should contain all fixes, changes, and additions between official releases of your project. It helps users and developers who upgrade to a new version to understand what has been changed or improved recently. See Commit messages for best practices on maintaining this file.
Example - Handbook page - Your project can have its own page or section in the Drupal Handbook. For instance, contributed modules can have pages in the contributed module section, and contributed themes go into the contributed theme section. A handbook page might (and probably should) repeat information from the "readme" and "install" files -- it should include information on how to install your project, how to use your project, and any pitfalls users might encounter. Supplying a few use cases can help a potential implementor to get a good idea on how your project can be used on his/her site. Once you have created a handbook page, add a link to the page in the "Documentation" section of your project page (this is a field on the Edit screen for your project, under Resources).
Example - Security announcement - There will be more on why you might need this on the next page.
Coding Standards
It is recommended that you install and use the Coder module. In addition to making sure you've adhered to the Drupal coding standards, this module also can give you performance hints and Drupal version upgrade advice.
Translation
Drupal has a diverse and international community. Many of your potential adopters are not going to speak English or want to have their sites in English. If your project is valuable to someone with a different language, they may very well step up and provide you with a translation ("po") file. You can help them out by providing them with a translation template ("pot" file) in your distribution.
Information on how to set up your module so it can be translated can be found in the Localization API section of the handbook. Information on extracting translatable strings is best done with the Translation Template Extractor module (more information about the Translate Template Extractor can be found here). Once you have created POT (translation template) files, and/or PO (translation) files, they should be placed in a subdirectory (of your module directory) called "po" (5.x) or "translations" (6.x). Use CVS > Add contents to tell CVS to include this file. Now when you commit your module, this template will be included.
Further reading:
Release management
There is a whole section of this handbook devoted to Release management and it's full of valuable information. If nothing else, please read the two page hand-out about maintaining releases that describes the essentials and best practices in condensed form.