Application workflow

Last updated on
20 August 2023

Before reviewing applications, please see Tools to use for reviews.

Workflow and status changes

The Needs work status should be reserved for major (high priority) issues. Minor changes, recommendations for full API compatibility, and README file perfection are not major issues. Holding up reviews on these changes can come off as unnecessary and nit-picky, especially early in the review process. This can also cause frustratingly long waits for uninitiated applicants.

An application whose status is Active isn't reviewed; we allow the user who created the application to tell us to wait to review the project used for the application. The only status used for requesting a review is Needs review.

The workflow for applying to security advisory coverage is the following.

  1. When applicants have fully prepared their code and supporting materials, they should change the issue status to Needs review.
  2. Once the status has been changed to Needs review by the applicant (and not by a maintainer/co-maintainer of the project used for the application or a different person) a Code Review Administrator will verify the applicant cannot already opt projects into security advisory coverage; the applicant did not open already an application that is postponed, waiting for the applicant to change any project file, waiting for review, or its status is still Active; the project used for the application contains enough PHP code and it has commits from the applicant, at least in the branch used for the application; the license file eventually present is not for a license that is different from the one used from Drupal core.
     

    It is important that what described in the second point is done before any code review is started. Telling to the applicant what to change in the project files, and then that the applicant does not need to apply to be able to opt projects into security advisory coverage because that permission is already given, or that the project does not match the criteria used to select which projects can be used for these applications, would not be a much positive experience for the applicants. 

  3. Reviewers will then review the project. If they don't find any flaw or problem with the code, they set the status to Reviewed & tested by the community.
  4. If there's a problem, or a clarification is needed after review, the question should be asked, and the reviewer should change the status to Needs work.
  5. If Code Review Administrators need more information, they change the status to Postponed (maintainer needs more info).
  6. The status will alternate between Needs review and Needs work until a conclusion is reached.
  7. When a reviewer is confident that the application can be approved, a status change to Reviewed & tested by the community will inform the Code Review Administrators who will do a final review and set the status to Fixed upon approval, or bump it back to Needs work if there are still changes required.
  8. Applications that are not appropriate for whatever reason, or applications whose status has been Needs work or Postponed for too long, are switched to Closed (won't fix).

The priorities used in the security coverage applications, what they mean, and when they are changed is described in the Issue priorities page.

Templates for feedback and notifications used in the process are available in the Template for reviewers. Those are a sub-set of the templates used by Code Review Administrators.

Examples of issues that warrant going back to Needs work

  • Creating a form outputting HTML markup instead of using the form API
  • Not sanitizing user input that is shown in a page or using the wrong function/method to sanitize user input
  • Concatenating strings to build the query string instead of using database query placeholders
  • Not using placeholders for translatable strings, especially when the string is built on user input
  • Not translating strings when they should be, or translating them when they should not be
  • Not checking the access to pages, or using the wrong permission to allow access to pages
  • Including third-party code
  • Sloppy formatting and not following the Drupal coding standards

Examples of review issues that won't block the application

  • Using lines longer than 80 characters in the README.txt or the README.md file
  • Not implementing hook_help()
  • Small, occasional formatting errors

Help improve this page

Page status: No known problems

You can: