Best practices for co-maintaining projects

Status: Work in progress. Contact sun (tha_sun on IRC) to discuss this page.

Note: This page describes best practices for co-maintaining a project. However, the following project maintainers consider these practices as rules and require all co-maintainers to fully adhere to them: sun, Dave Reid, and KiamLaLuno [Add your name here].

Applying as co-maintainer

• CVS access is not granted blindly. Applicants should already have read each issue and participated in many issues in a project's queue, helped with support requests, provided patches, and be involved in architectural and technical discussions. Ideally, applicants are also available in IRC.
• One of the other project maintainers should have committed 3-4 of your patches without any objections or remarks.
• Create an issue with the title "Applying for CVS access" and describe your motivation.

Contributing code

• All code fully adheres to Drupal's coding standards, Drupal's standards for comments, as well as the other handbook pages about development standards.
• All code complies to Coder module's rules.
• Patches need to be supplied for every branch of a project (if applicable).
• In general, all changes should be discussed in separate issues. You should create issues for almost all changes, even if you could commit them directly. This does not only give others a chance to review and comment on them, but is also the only working solution to properly follow Drupal's guidelines for commit messages.
• Likewise, when porting a module to a new version of Drupal core, changes should be kept as minimal as possible. This means: no code clean-up, no new features.

Committing code

• No code and no changes are committed without a corresponding issue on drupal.org.
• Patches need to be reviewed by other users and must be in RTBC state before committing them. Ideally, another maintainer of the project reviewed a patch and had no objections.

  However, if patches are unnecessarily hold-off because of missing reviews, then they should be committed, so development can go on. Most often, developers are involved in a bunch of other projects.

• Before committing any change, a new changelog entry is added to CHANGELOG.txt, which adheres to the best practice for commit messages.
• The changelog entry is used identically for the commit message, without line-feeds though.
• If the primary maintainer granted you CVS access to maintain a certain part of a project only, you will not commit any changes that affect other parts of the project or module.
• Again, no commit without an issue.

Coordinating development and releases

• To coordinate the ongoing development and goals for a certain project release, a release coordination issue is used that covers and links all required tasks.

  Examples: Administration menu 6.x-1.2, Image Assist 2.0, Guestbook 2.0.

Creating releases

• In 5.x-2.x, 2.x is the actual version of the module in question. When porting a module to a new Drupal core version, the new version is 6.x-2.x (not 1.x). "2.x" describes a certain feature-set. Drupal core versions are not renumbered with each new Apache or PHP release either.
• In front of creating a new release, CHANGELOG.txt has to be updated to reflect the new version, as described in the best practices for commit messages.
• Before creating a new release, tests need to be run and complete without failures. Additionally, a test of the major module functionality needs to be done manually.
• The release notes for a new release are generated using the cvs-release-notes script, as described in the best practices for commit messages.