Reviewing Project Application - Instructions

NOTE: PLEASE FEEL FREE TO ADD AND EDIT!

What is it?

The ‘Project Application’ process is the means by which new module/theme contributors can apply to include their project on Drupal.org, and be granted the ‘Create Full Projects’ permission on the d.o site. At any given time, we have nearly 150 projects waiting in a ‘needs review’ state … thus, we desperately need your help!

What’s involved?

Goals of the Code-Review Group:

1. Put a significant dent in the Project Applications ‘needs review’ queue.
2. Reduce the ‘manual’ component of the review process, through the automation of common review tasks and development of new review tools.
3. Audit the existing Project Application documentation and ‘new contributor’ process, identifying opportunities for improvement and implementing solutions where possible.

How can you help?

We’re looking for assistance in a number of areas. Anyone can get involved … whether you’re a themer, developer, site builder, existing applicant, or drupal novice, we’ve got a part for you! See the following sub-categories for more information.

1. Review an application
2. Test a project
3. Improve Documentation
4. Improve Process
5. Improve Automation

Option 1: Review an Application

The primary job of an application reviewer is to help mentor the project submitter, ensuring that they are aware of and abiding by Drupal’s 'standards, security, and best practices' in writing their module. Failure to abide by the licensing and security components of these best practices will result in an application being blocked. The coding standards and documentation components should be considered as secondary but ‘important’ … in that the application should demonstrate awareness and knowledge of the corresponding best practices, but enforcement of these standards should not require 100% compliance before approving an application.

Whether performing a deep dive review, or simply triggering a ventral.org automated code style review, performing the following common steps will help us with administration of the sprint:

• Search the Full Project Application queue and choose an unassigned application to review.
  Consider filtering the list by ‘last updated’ or ‘oldest created’ to help identify those projects which have been waiting the longest.
• To make sure that the application your working on is not reviewed by someone else already, set the ‘assigned’ field to your drupal.org username to help avoid overlap with other sprint participants, and remove it once you are done with that application.
• If any issues are flagged, identify them in the project application issue thread, and set the application to 'needs work'.
• Remember ... your role as a reviewer is to ‘identify and educate’, not to play ‘enforcer’. Unfortunately, an applicant’s natural tendency is to see reviewers as the ones setting up the roadblocks between them and application approval. To help counter this, choose your wording carefully when responding in an application thread … make recommendations, not demands.

Review Steps

1. Basic application process checks (novice)

Ensure application contains a repository link

Ensure it's not a duplication (ask for differences and suggest co-maintainership)

2. Basic Git Repository Sanity checks (novice)

Project repository contains code

Project has correct repository branch/tag naming

3. Licensing checks (novice)

Repository doesn’t contain a ‘license.txt’ file (added by Drupal’s packaging scripts)

Project doesn’t contain any 3rd party (non-GPL) code

4. Documentation checks (novice)

Project page contains a clear description of the project and it’s purpose

Project repository contains a clear README.txt, which includes installation instructions

Project files include a @file and per-function PHP docblocks

5. Code Style review (novice)

If not already done, submit the project for review at http://ventral.org/pareview and provide a link to the results (or post as an attachment) in the application thread. Please do not paste the full results in the thread, as giant ‘wall-of-wrong’ posts are extremely demotivating to applicants.

6. API Review (developer)

This is a deeper dive through the project code (often line-by-line), looking for proper use of Drupal’s APIs. The most common item found here is lack of (or improper) use of t().

7. Security Review (developer)

Coincides with the API Review, and involves validating that the code does not contain any security vulnerabilities. The most common issue encountered here is failure to sanitize output, and/or direct use of $_GET/$_POST parameters.

Resources

• Text-templates for typical issues
• How to install PARview.sh locally
• Issue overview (more clearly)
• Activity cloud about current participation

TODO: Add more reviewer resource links

Option 2: Test an Application

This option consists of actually downloading the applicant's project from their project repository, installing it on a drupal site, and validating that it works as advertised. Take note of any error or warning messages which are encountered during the installation and/or operation of the module, and list them in the project application's issue thread.

Option 3: Improve Documentation

This option consists of reviewing the existing project application documentation, and identifying potential opportunities for improvement. As someone new to the process, how easy is it to find the documentation? Are there parts of the documentation which are misleading or are not clear? Are there items being flagged in the review process which are not discussed in the 'pre-requisites' documentation? Essentially, are there any improvements you can identify that would help make the process easier on potential applicants and/or new reviewers?
TODO: Identify existing documentation pages

Option 4: Improve Process

Had your fill of code for the week, and want to participate in a larger 'meta-discussion' instead? There have been a number of proposals put forward as to how to improve the overall process, but community consensus has been hard to come by ... get together with us and contribute your thoughts as to how we can improve this process and the new project contributor on-boarding experience!

Option 5: Improve Automation

The one thing we've been able to agree on is that automation can help reduce the reviewer workload, and speed up the application-to-approval timeline ... chip in and contribute to the coding effort towards automated project application testing!
TODO: Identify automation opportunities and break down into individual chunks/tasks.