Skip to content

Working on a project with more than one maintainer

This page outlines the best practices to follow when you are one of the maintainers a project has, to avoid conflicts and work together as a group to improve the project. See also Dries' blog post on Responsible maintainers.

Code guidelines

  • All code fully adheres to Drupal coding standards.
  • All text visible to the user is translatable.
  • All code complies with Coder module review rules.
  • All changes, especially new features and improvements, are done for the newest official branch first and possibly back-ported afterward.
  • Each change is discussed in a separate issue.
  • Create issues for almost all changes, even if you could commit them directly. This not only allows others to review them, but it 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, which means no code cleanup and 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 to allow understanding how to update dependent code to next major release.

Committing guidelines

  • No non-trivial changes are committed without a corresponding issue on drupal.org.
  • Merge requests need to be reviewed by others. Ideally, another project maintainer reviewed them and had no objections; however, if merge requests are unnecessarily held off because of missing reviews, then they should be committed.
  • Follow the best practices for commit messages.
  • If you've been granted commit access to maintain only a certain part of the project, then you will not commit any change that affect other parts of the project.
  • Discuss and coordinate the ongoing development and tasks for a certain release by creating a release coordination issue.
  • Use [project name] [new version] as issue title.
  • Use the issue summary to outline and link to all issues, ideally categorized. This allows you to edit and update the list afterward.
  • Before creating a new release:
  • Automated unit tests need to be run and complete without failures
  • The primary/major module functionality needs to be tested manually