Last updated 22 January 2016.

This page describes the 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, kiamlaluno, plach, voxpelli, tstoeckler, podarok [Add your name here].
The formal process of looking for new (co)maintainer is described here.

Applying as co-maintainer

Everyone can submit patches to every project at any time. Co-maintainers are individuals who can commit patches and thus change the code of a project. Next to becoming a co-maintainer, abandoned and inactive projects can be taken over; learn how.

  • Commit access is not granted blindly. Applicants should have already 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 or other instant messaging tools used by the project maintainers.
  • Project maintainers should have committed 3-4 of your patches without any objections or remarks. Too simple patches do not count.
  • Create an issue with the title Applying for commit access and describe your motivation.

Contributing code

  • All code fully adheres to Drupal's coding standards, Doxygen, commenting, and documentation standards, and all other development standards handbook pages.
  • All code complies with Coder module's review rules.
  • All changes, especially new features and improvements, are done for the newest official branch first (master or latest core compatibility) and possibly backported afterwards.
  • If applicable, patches should be supplied for every branch of a project. However, focus on the latest major version first.
  • Discuss all changes in separate issues. Create issues for almost all changes, even if you could commit them directly. This not only allows others to review them, but is also the only way to adhere to Drupal's guidelines for commit messages.
  • When porting a module to a new version of Drupal core, keep changes minimal and focused. Meaning: no code clean-ups, no new features.
    • Defer larger improvements, rewrites, and optimizations to separate follow-up issues, in case the new Drupal core allows for any. They can be done later, and depending on API changes, possibly in a new major version of the project.
    • The goal is to make fast progress, allowing users to adopt the new version of Drupal core and your project.
    • Read and understand the meaning of major versions below.
    • Create project's change records for ability to help other developers to understand how to update dependent code to next major release.

Committing code

  • No non-trivial changes are committed without a corresponding issue on
  • Patches need to be reviewed by others and must be in RTBC state before committing them.
    • Ideally, another project maintainer reviewed them and had no objections.
    • However, if patches are unnecessarily held off because of missing reviews, then they should be committed, so development can go on. Project maintainers are often involved in many other projects, and they have a life, too.
  • (optional) Before committing a major change, add a change log entry to CHANGELOG.txt that summarizes the change. Wrap the text at 80 characters. Some projects are listing all changes in CHANGELOG.txt; you should follow the existing or agreed-on practice.
  • Follow the best practices for commit messages.
  • If you've been granted limited commit access to maintain a certain part of the project only, then you will not commit any changes that affect other parts of the project.
  • Again, no commit without an issue.

Coordinating new releases

  • Tag all issues that prevent a new release with Release blocker.
    • Do not use version-specific release blocker tags. The combination of the tag and the assigned version of an issue is sufficient.
  • Discuss and coordinate the ongoing development and tasks for a certain release by creating a release coordination issue.

Creating releases

  • In 5.x-2.x, the actual version of the module is 2.x.
    • The actual version 2.x describes a certain feature-set.
    • (optional) When porting a module to a new Drupal core version, the new version is 6.x-2.x (not 1.x).
  • Before creating a new release,
    • (optional, if using a changelog)CHANGELOG.txt has to be updated to reflect the new version number.
    • automated unit tests need to be run and complete without failures.
    • the primary/major module functionality needs to be tested manually.
  • Use drush release-notes to create the release notes for the release node on, as described in the guidelines for commit messages.