How is lowering the barrier to become a module maintainer

Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.

Before anything else, I want to point out that while this post will focus on maintaining a contrib module on, that is just one of the many ways to contribute to the Drupal project. Every contribution is important whether it's a core patch, a documentation edit, a translation, or something else. If you use Drupal, please consider how you might be able to give back to the community. If you're already contributing, then thank you!

If you're contributing your first module to, the process starts with obtaining GIT access and creating a sandbox project. Once you've done that and you're confident that your module is ready for general use, you must go through a one-time approval process to promote your sandbox project (and any future projects) to full project status. It's difficult to deny that having some sort of manual review process is important but as someone who has been through the process I can attest that it can be frustrating at times.

Several months ago, there was a change to the project application process proposed. The general idea was to let users who haven't finished the application process get an installable release and reserve a namespace while still preventing insecure and poorly coded modules from being published on

More recently, at DrupalCon Los Angeles, David Hernandez (a member of the Software Working Group) and Michael Hess (Security team lead) gave an excellent presentation about some of the changes that are being implemented as a result of the proposal and discussions between various working groups. Some of the key takeaways from the presentation:

  • Automated code review tools have been integrated into the infrastructure and all projects will be subject to the scanning process with a summary of the results visible to everyone.

  • All projects, even ones created by git vetted users, will have to start with a sandbox project and pass the automated scan before the owner can promote the project.

  • Non-vetted users (users who have not had a module go through the manual review process) will be able to promote one sandbox project to a full project but it will only be able to have development snapshots (no beta, 1.x, etc releases) and the project page will indicate that it is maintained by a non-vetted user and not subject to security advisories

  • The manual reviews will no longer be as strict as they were in the past. Instead of flagging every minor issue, the reviewers will focus on security, whether everything is properly licensed, and whether it's clear that the maintainer understands the Drupal API (this is already being done by many reviewers but will now become an official policy).

Overall, anything that might help increase participation in the Drupal community is a good thing. The various working groups have done an excellent job balancing that with the need to maintain quality and security and I look forward to seeing the changes in action once they have been fully implemented.

If you're interested in finding out more about the future of of the project application process, check out the video of presentation below.