Recommendations for the speediest reviews

Most pull requests can be approved more quickly if these guidelines are kept in mind during development:

• Remove unused or unnecessary code that does not need to be reviewed from the master branch.
• Make sure all code has been run through PHP Code Sniffer using the VIP Coding Standards, and that as many blockers as possible have been addressed.
• Obtain internal reviews before opening a pull request on master; as explained in the workflow for non-production environments, you can do an internal review by targeting a different branch such as develop. The VIP code analysis bot will recommend changes on any pull request.
• Only open a pull request on master after all development, internal reviews, and PHPCS fixes are complete.
• Submit the PHPCS output.
• Be ready to enter a code freeze during the code review process.
• Avoid making changes to an approved pull request – if possible make those in another branch, or wait until the changes are merged.
• Separate pull requests should be employed for any of the following scenarios:
  • Extensive whitespace changes (for example, fixing tabs and spacing).
  • Changes that are limited to style only (for example, revising variable names, formatting, comment blocks, etc).
  • Addition of a plugin (one pull request per plugin is best).
  • Removal of plugins, or several files.
  • When multiple, distinct features are changing that, combined, affect more than 1000 lines of code or more than 50 files.
  • A build step that results in minified or compiled JS and CSS (also consider using our Built Branches).
• Pull requests that contain only CSS changes (or do not contain files with extensions that we review) will be auto-approved.
• When making fixes to a review that had Request Changes reviews, try to make only one or a few commits – this can be looked at separately.
• Be sure to dismiss an approval review if you need to make an additional change for any reason, and try to limit those changes to one commit, or merge the reviewed pull request and open a follow up one.
• Pull request commit messages and the initial comment are helpful to us and we do read them; summarize the intent of the changes and add detail about complex abstractions.
• If your pull request is related to an open help desk ticket, please provide a link to that ticket in the comment.
• Once a pull request is created, open it in GitHub and confirm there are no changes included that were not intended, especially if there were .gitignore file changes.

By creating separate pull requests for smaller changes, each review is simplified and can be completed more quickly. When there are many files, many PHPCS warnings or errors, or many commits after the initial review, it becomes more complex, and sometimes more difficult to use Github’s built-in tools to provide review feedback.