Application workflow

Workflow and status changes

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

1. Once the application has been created, a project moderator will verify:

   • The applicant cannot already opt projects into security advisory coverage.
   • The applicant has not already created an application which is still open.
   • 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.
2. When applicants have fully prepared their code and supporting materials, they should change the issue status to Needs review.
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. It is preferable not doing that on the first review, and that another reviewer confirms there is no flaw or problem with the code before setting 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 project moderators 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 project moderators 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. The status of applications that are not appropriate for whatever reason is changed to Closed (won't fix).
9. Applications whose status is Needs work a year after they have been created, and whose priority has been Low for at least six months, will be closed as Closed (won't fix). Applicants can still re-open them, if they are willing to continue the application and they changed what the review suggested to change.

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 project moderators.

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 changes that should not block the application

These are examples of changes that should not block the application, except in the case the review is the first review done or there are other changes that should be done.
Furthermore, if a previous review asked for these changes, but the project files have not been changed to reflect them, a new review can still ask for these changes.

• Changing the README.txt or the README.md file to make each line shorter than 81 characters
• Implementing hook_help()
• Fix small, occasional, formatting errors