Last updated March 9, 2017.

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.

1. Basic application checks

1.1 Ensure your application contains a repository and project page link.
To make it easier for reviewers to find the needed resources, make sure your application issue contains a link to the project page and a working "git clone" command.

2. Basic repository checks

2.1 Ensure the repository actually contains code.
On drupal.org we use GIT repositories to share code. If you haven't yet pushed code to your 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.

3. Security Review

3.1 Ensure the project does not contain any security issues.
Coincides with the API Review, and involves validating that the code does not contain any security vulnerabilities. This step is the most important one in the whole process and we highly recommend reading through the documentation about writing secure code.

4. Licensing checks

4.1 Ensure the top directory of the repository does not contain a ‘LICENSE.txt’ (or similar) file.
Do not include a LICENSE.txt file in your repository. Drupal.org will add the appropriate version automatically during packaging.
4.2 Ensure the repository does not contain any 3rd party files or non-GPLv2+ materials.
Third party code and assets (e.g. media files such as fonts, images, videos and sound, and text.) are not generally allowed on Drupal.org and should be deleted. This policy is described in the getting involved handbook. It also appears in the terms and conditions you agreed to when you signed up for Git access, which you may want to re-read, to be sure you're not violating other terms.
For PHP code not hosted on Drupal.org, the preferred mechanism for adding 3rd party dependencies without directly including the code in the Drupal.org repo is referencing the package via a composer.json file.
For other dependencies, the Libraries API module is a recommended method for adding 3rd party dependencies without directly including the code on Drupal.org.

5. Documentation checks

5.1 Ensure the project page contains detailed information.
Project pages should be helpful; there are literally thousands of modules, themes and installation profiles and 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-tags for better structure.
5.2 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. Please make sure you have a README-file that follows the guidelines for in-project documentation and is based upon the README Template. The contents of the file may be a repeat of the synopsis on the project page.
5.3 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 the module documentation guidelines and the Doxygen and comment formatting conventions

6. Coding standards and style

6.1 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.

A commonly-used tool that you may try is pareview.sh/. It is the product of the PAReview.sh project, and it utilizes the Coder (and Coder Sniffer) tools that can, if desired, be used independently of PAReview.sh.

Note that issues found are possibly false positives and fixing all issues is not a requirement for getting through the application process. Automated reviews may point you to possible security issues - what does not mean they are really security issues - note that it's a common case that automated reviews can have false positives.

7. API and best practices Review

7.1 Ensure you are using Drupals API correctly.
This step is a deeper dive through the project's code (line-by-line), looking for proper use of Drupal's APIs. Surely we can't demand this to be perfectly resolved by applicants but we can give you some hints what mistakes are commonly done.