Application checklist

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.

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.

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.

Application checks

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

While security advisory coverage applications use a project, their purpose isn't changing the project status. They give to the person who applies a new drupal.org role which allows to opt into security coverage any project created from that person. To do so, the reviewers check whenever the project contains secure code that follows the Drupal coding standards and correctly uses the Drupal API. It's not easy to understand how much the person who applies understands about those topics when the code has been written and committed by more people.

Ensure your application contains the project page link

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.

Repository checks

Ensure the branch used for the application is compatible with a supported Drupal version

We only review code that is compatible with a supported Drupal version. This makes possible for everybody to review the project used for an application, which makes approving the application quicker.

Ensure the branch used for the application contains enough PHP code

PHP 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 branch used for the application 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.

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.

Ensure there are no security issues in the project

The absence of security issues in an important point. Reading through Writing secure code for Drupal is highly recommended.

Coding standards and style

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. In particular, GitLab CI is now available for all the projects, and it should be used to fix issues in the project code.
Note that the found issues could also 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

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.

Since the number of classes which are part of Drupal core increased starting with Drupal 8, it is also necessary to verify that the class used as parent class is part of the public API, as described in Drupal core backend backwards compatibility and internal API policy (Drupal 8 and above). As for classes containing static methods, those are public API, but that page reminds that developers should be prepared to any changes done to the classes.

Documentation

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.

While the community described the format to follow for the README.md file, the Markdown coding standards are still to be written. If the README.md file is formatted following what reported in README.md template, that file could need to be changed basing on what the coding standards will report.

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.