Note: The following is provided as a suggested 'checklist' for code reviews, with some modifications to the existing process thrown in.
The largest change is a divergence from the "Stick to a review from start to finish" concept, as the proposal below would encourage folks to jump on/off at the start/end of any given gate. The motivation behind this is to allow for less experienced reviewers to get involved in the review process without committing to a full review (as the 'full review' commitment can be a bit daunting for a new contributor).
A second suggestion is the use of tags to validate the clearing of each gate, as discussed in other sections of this group. While there is consensus within the group that tagging gates could become unwieldly; auto-creating tags is not something that can be done today 'out-of-the-box' ... so I've attempted to group the checklist into sections, thus minimize the tags used while still providing the abililty to use tagging to indicate where an application sits in the process.
The third is the addition of an 'Applicant Review' gate. I personally feel that the linkage between 'Module Review' and granting of the 'Full project access' roles should be severed, allowing the flexibility within the process to grant one without a dependancy on the other (think '3 module reviews = full access', or 'Module denied, but access granted' situations) ... which would then allow a 'probationary' period for new applicants, where we can ensure they are up to speed on managing the issue queue, project packaging, and git best practices before setting them free in contrib.
In any case, my proposed 'checklist' is posted below - feedback, comments, suggestions for improvement are encouraged!
(Proposed) Full Project Application Review Checklist
Gate 1: Pre-Screening
"Pre-screening" step can be performed by pretty much anybody (other than the applicant)
Identity Check
- Good Project Title
-
Project Page contains a detailed description
- Concise introductory ‘overview’ (purpose should be clear in first few sentences)
- Describes what the module does
- Who is the module’s intended audience
-
Application includes a link to the Application Sandbox
- Innovation – Module provides something ‘new’
Once all gates passed, tag with ‘CR:PreScreeningCleared’
Gate 2: Initial Review
"Screening" step can be performed by pretty much anybody (other than the applicant), but analysis could be subject to further review
License Check
- No License.txt Files
- Code doesn’t include any 3rd party libraries
Based on the amount of discussion this has caused on existing threads, I figured it deserved its own gate.
Duplicate Module Check
- Search for Modules with similar functionality
- Better off collaborating with an existing module author?
- Promote collaboration over competition
Once all gates passed, tag with ‘CR:ScreeningCleared’.
Gate 3: Technical Review
This is the bulk of the actual detailed 'code review' process, where some advanced knowledge/experience may be required.
Best Practices
- Makes effective use of Drupal APIs
- Makes effective use of the Theme layer
- Makes effective use of jQuery for javascript code (ie. Drupal.behaviors)
- Extensibility (provide API for other modules)
- etc.
Security
- All user-submitted content is filtered before output
- Code uses proper database access functions and placeholder syntax
- etc.
Once gates passed, tag with ‘CR:NeedsPolish’ or 'RTBC'
Gate 4:Polish
Coder Check
- Runs through ‘Coder’ Module cleanly
Basic Coding Standards
-
Doxygen blocks and comments (content analysis)
- Good function summaries & In-line comments
- Proper English (documentation code standards)
-
Proper opening php tags (long form, not short); no closing tags
Detailed Coding Standards
- Module name-spacing used on functions and variables
- Any custom variables are removed on uninstall
- All user interface strings run through t()
- etc.
Repository Check
- Ensure repository actually contains Code (may have empty ‘master’ if it also contains a named branch)
- Basic Formatting (Spacing/Indentations)
- No CVS ID Tags
- Documentation blocks for (both ‘File’ and ‘Function’)
Documentation Check
- Contains a README.txt
- Implements hook_help()
- Doxygen style comments exist for all functions
- Doxygen @file blocks exist for each file
Gate 5: Applicant Review
Hopefully, by the end of the review process, we have a good idea of the applicant’s capability regarding the following.
Issue Queue Management
- Demonstrated knowledge of how to manage their issue queue
Git Best Practices
- Demonstrated knowledge of git practices (branches, creating patches, applying patches, etc.)
Packaging and Naming
- Demonstrated knowledge of Drupal packaging/branching/naming conventions