Advertising sustains the DA. Ads are hidden for members. Join today

Application checklist

Last updated on
24 August 2023

See also Useful tools, which describes the tools which can help you find what needs to be changed in the project files.

This checklist basically covers all points of the application process a reviewer will take care of. We know that not all new contributors have the knowledge to successfully follow all of these points from scratch, but the more of them you can resolve now, the less reviewers have to remind you later and the quicker your application can be approved.

Basic account checks

Ensure you aren't applying using a shared account

Shared accounts aren't allowed to commit code in Drupal.org repositories as per Drupal.org Term of Service / Accounts. For that reason, applications created using a shared account will be closed as won't fix.

Instead, each developer needs to create an account that is used only by a single person and apply using that account.

Ensure you aren't already able to opt projects into security coverage policy

If you are already able to opt projects into security coverage, you don't need to apply to get that permission.

Basic application checks

Ensure you don't have multiple applications open

As successful completion of the project application process results in the applicant being granted the vetted role, there is no need to take multiple applications through the process. Once the first application has been successfully approved, the applicant can opt into security coverage advisory for other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers.

Use a project for which you committed the code in at least a branch

While the security advisory coverage applications use a project, their purpose isn't changing the project status, but giving to the user who applies a new Drupal role that allows to opt into security coverage in any project created from that user. To do so, the reviewers check what the user understands about writing secure code that follows the Drupal coding standards and correctly uses the Drupal API. It's not easy to understand what the user who applies understands about those topics when the code has been committed from more users.
To make it easier for reviewers to review your project, make sure the application issue you created contains a link to the project page.

Ensure the application status is set to Needs review

We allow users to create an application before the project is ready to be reviewed. The Active status is used to indicate the project is not ready to be reviewed. When the project is ready for review, change the status to Needs Review.

Basic repository checks

Ensure the repository contains enough code

The code is used to verify what the users who apply understand about writing Drupal code. It's not possible to understand that when the project contains few code lines (for example, a single hook implementation).
If you haven't yet done any commit to the project's repository because you don't know how, please have a look at the documentation about using Git on drupal.org or watch this video.

Ensure the repository actually contains PHP code

A project used for these applications needs to contain PHP code. Projects that contain only text files (including YAML files, or the README file), document files (for example PDF files or text processor files) media files (images, video and audio files), or code written in other programming languages (including markup files, HTML, XML, etc) cannot be used for these applications.

Ensure the repository isn't using the master branch, or branches with the wrong name

On drupal.org the master branch isn't used. Instead, create a branch for each supported Drupal version, following the naming standards reported in Release naming conventions for branch names and third-party projects.

Licensing checks

Ensure the repository does not contain code that is incompatible with GPLv2+

All code that is a derivative work of Drupal (typically PHP code), including modules, themes, and installation profiles hosted on Drupal.org, is licensed under the same license used for Drupal: GPL version 2.0 and later. It's not possible to license modules, themes, and installation profiles hosted on Drupal.org under a license that is different from the one used from Drupal.

Make sure you've read and understand Drupal Git Contributor Agreement & Repository Usage Policy and Policy on 3rd party assets on Drupal.org

Having third-party libraries in your repository is strongly discouraged. Please read Including 3rd party libraries to learn how to include third-party libraries.

Security Review

Ensure the project does not contain any security issues

The code should not contain any security vulnerability. We highly recommend reading through Writing secure code for Drupal.

Coding standards and style

Run an automated review and ensure there are no major issues

As coding standards make sure projects are coded in a consistent style, please follow them whenever possible.

In addition to validating that your module is aligned with Drupal's coding standards, there are several available tools which can automatically detect and flag a number of common security issues which would otherwise delay approval of your application.

Note that the found issues could possibly be false positives; before applying any suggested change, you should verify they are effectively necessary.
Automated reviews may point you to possible security issues; this doesn't mean they are really security issues.

API and best practices Review

Ensure you are using Drupal's API correctly

This step is a deeper dive through the project's code (line-by-line), looking for proper use of Drupal APIs. What reported in Writing secure code for Drupal and Tips for ensuring a smooth review / Your project contains non-secure code also help to correctly use the Drupal API.

Documentation checks

Ensure the project page contains detailed information

Project pages should be helpful. There are literally thousands of modules, themes, and installation profiles; site builders need a clear way to understand what a project does. Please have a look at the tips for a great project page; you may also use HTML markup for better structure.

Ensure the repository contains a detailed README.txt or README.md

Every contributed project should provide a README file in the package. This file should contain a basic overview of what the module does and how someone may use it. Module documentation guidelines and README.md template should be used to write that file.

Ensure the code contains a well-balanced amount of inline-comments

Make sure your code is well commented and clearly understandable by other developers. Please have a look at Module documentation guidelines and API documentation and comment standards.

Help improve this page

Page status: No known problems

You can: