Guide to Requesting Code Reviews

VIP Go platform specific

This document is for sites running on VIP Go.

Learn more

Code review will operate on a request-by-label basis for clients on VIP Go as of July 15th, 2020.  


  • To request a review from WordPress VIP, please add the label “[VIP] Review Request” to the pull request
  • A review is no longer mandatory, so branch protection rules have been removed
  • You can now leverage GitHub protection rules that work best for your team’s workflow

What has not changed

  • The PHPCS bot will continue to run on all new pull requests in any branch
  • Service level agreements regarding review timeliness remain unchanged
  • Branches, previously not reviewed by WordPress VIP, will remain un-reviewed
  • No changes for sites on (SVN)

Why the change?

This new process will empower developers to choose when and which pull requests should be reviewed by WordPress VIP, because we recognize that many updates do not require review.

Frequently Asked Questions

How do I request a review?

If you would like a review on your pull request before merging to production, add the label* “[VIP] Review Request“.  Please note that pull requests without the label will not be reviewed.

You can find the labels in the GitHub UI on the right sidebar of your pull request:

* This label will become available on all applicable repositories prior to July 15th, 2020.

Do I need to request a reviewer?

No, simply add the label from the available list of labels when your pull request is ready for review.

How do I merge without review?

After opening a pull request, you may merge to your production branch by clicking on the “Merge pull request” button near the end of the pull request:

Has anything changed in my GitHub repository?

Yes, we’ve added a new label ([VIP] Review Request) and modified the branch protection rules for your primary branch.  However, you are welcome to modify the branch protection rules as needed (e.g. to customize a workflow):

Pull request reviews are no longer required.

When should I skip a review?

We recommend reviews for pull requests with security or performance implications. Reviews are also helpful if your team has questions about development best practices.

For smaller and less complex changes, a review may not be necessary. For example:

  • CSS changes
  • Re-compiling of assets
  • Changes to readme, build scripts, ads.txt, and other non-code files
  • Third-party library or plugin updates (via composer, npm, etc.)
  • Reverts of previous pull requests
  • Immaterial changes such as changing strings or variable names, whitespace changes, reformatting, and other minor refactors

How do I set my own branch protection rules?

Branch protection rules are a set of configurations that allow repository administrators to enforce security policies (i.e. ensuring code is reviewed, preventing accidental branch deletions, etc.) and to require successful automated checks before pull requests can be merged.

Go to your repository branch settings ({myrepo}/settings/branches), choose a branch, and begin customizing.  More information about branch protection rules. Please note: rules can be customized after  VIP’s branch protection rules are removed on July 15th, 2020. 

What can I use branch protection rules for?

GitHub continually adds features to their protection rules, but here are some current potential use cases for imposing restrictions:

  • Ensuring that the PHPCS bot scans all changes by enforcing pull requests on certain branches
  • Internal code reviews on pull requests by requiring at least one approving review before merging
  • Restricting which users can merge pull requests

What types of workflows can I use for pull requests?

You may combine branch protection rules and GitHub’s pull request features with your own internal processes and/or tools to customize your workflow. Some examples:

  • If you have your own private repository and CI/CD creating pull requests in your VIP repository, you can automate selectively adding the label to pull requests (i.e. if your release manager gives it a “Needs VIP Review” label in the private repo, your automation adds the VIP label in the VIP repo)
  • If you would like to start (or already have been) requiring internal reviews on pull requests, you can re-establish the rules to require pull requests
  • If you have certain designated team members to decide when to merge a pull request, you can add their names to a list of people allowed to merge
  • WordPress VIP has a CI/CD option that can be used post-merge to run code builds, so that only source files are present in your main branch and built files are not part of a changeset during reviews

What if I want to require review on all PRs?

We understand that some WordPress VIP clients may wish to continue with the required review policy for the foreseeable future, or may not wish to change an existing custom review configuration (i.e. for dual-deployment). If these situations apply to you, please reach out to your Relationship Manager or VIP Support, and we’ll be happy to discuss your needs and ensure that your repositories reflect your requirements.

What if I have concerns or questions?

We realize everyone has a different workflow and we are here to assist you with this change. Please reach out to your account team or open a ticket with us.


Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.