Recommendations for the speediest reviews

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

• 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 (or requesting review on) a pull request for VIP review; after all development, internal reviews, and PHPCS fixes are complete.
• Once a pull request is awaiting review, development should be complete, aside from addressing review feedback from the bot or the VIP reviewer’s comments.
• 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 any files with extensions that we review, such as php and js) will be auto-approved.
• When making fixes to a review, try to minimize the number of new commits, so that our reviewers need only look at the updates.
• Be sure to dismiss an approval review if you need to make an additional change for any reason, and need a new review.
• 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.