Process Code review
Two human reviewers on every PR to main. Automated CI gates before review. Branch protection enforces the rule at the GitHub level. No exceptions.
Code review is not a polite formality. It is the load-bearing quality gate before code reaches production. The standards below are enforced by branch protection rules in GitHub, not by trust alone. The two-reviewer rule has caught production-affecting bugs every quarter we have measured.
The six steps
Six steps from PR open to merged code. Same flow for plugin work, theme work, custom development, and customer-facing changes. No special-snowflake bypass paths.
01
Self-review the diff before requesting review. Confirm tests pass locally. Confirm WPCS, PHPStan, and lint gates pass. Add a description that explains the why, not just the what.
Reviewers see well-prepared changes, not work in progress.
02
GitHub Actions runs the full test matrix, WPCS, PHPStan level 5, lint, security scan. Failed checks block the merge. No manual override path. CI takes under five minutes for most plugins.
Mechanical issues caught before human time spent.
03
A second engineer reads the diff line by line. Asks questions. Suggests edits. Approves only when the change is correct, the tests cover the behavior, and the documentation is updated.
Code quality stays high without bottlenecking on one senior.
04
For PRs targeting main or release branches, a second reviewer also approves. The two-reviewer rule is non-negotiable for production-bound code. For long-running feature branches, one reviewer is enough.
Production branches never merge on a single signature.
05
Author responds to every comment, either with a fix, a counter-argument, or a follow-up issue. Reviewer re-reviews after fixes. Iteration continues until both reviewers approve and CI is green.
No drive-by approvals, no ignored feedback.
06
Squash merge by default for cleaner history. Tagged releases for plugins. Deploy hooks fire on merge for sites we operate. Author monitors the first few minutes after deploy.
Every merge is a deliberate decision, not an accident.
WPCS WordPress-Extra coding standards. PHPStan level 5 with WordPress stubs and per-project baseline. PHPUnit test matrix across PHP 8.1, 8.2, 8.3, 8.4 and WordPress 6.7, 6.8, latest. ESLint plus Prettier for any JavaScript. PHP lint for syntax errors. Security scan for common vulnerabilities.
All gates run in GitHub Actions on every push. No flag to skip. No path to merge with red CI. Engineering lead can override only with documented justification, which has happened twice in the past 18 months.
Correctness against the acceptance criteria. Test coverage for the changed behavior. Documentation updated where appropriate. Security implications for any user-facing or AJAX-handling code. Performance implications for anything in a hot path. Naming and structure that match the rest of the codebase.
Any PR touching authentication, authorization, AJAX handlers, REST endpoints, file uploads, or database writes gets a security review by an engineer with security focus. The security review is in addition to the two-reviewer rule, not in place of it.
We do not run gated reviews where a senior must approve every PR. We do not run review-by-comment-count theatre. We do not block PRs over personal style preferences. The review is about correctness and quality, not about gatekeeping.
Common questions
For projects where Wbcom is the only engineering team, the two reviewers are two Wbcom engineers. For projects with embedded customer engineers, one Wbcom and one customer engineer is the default. Either way, two human reviews on every production-bound PR.
No. Self-merge bypasses the two-reviewer rule. Branch protection on production branches blocks self-merge at the GitHub level.
Backup reviewers are assigned during sprint planning. No PR waits more than 24 business hours for a first review. If both primary and backup are unavailable, the engineering lead reviews.
Hotfixes follow the same two-reviewer rule. The review is faster (often under an hour) but it still happens. We do not merge hotfixes on a single signature.
WPCS WordPress-Extra ruleset for WordPress plugins, PHPStan level 5 with WordPress stubs, ESLint plus Prettier for JavaScript. All gated in GitHub Actions on every push. Test matrix covers PHP 8.1, 8.2, 8.3, 8.4 and WordPress 6.7, 6.8, latest.
“Wbcom Designs was methodical, reliable, innovative, and knowledgeable. They communicated with us every step of the way and delivered on time and on budget.”
“A partner, very trustworthy, very reliable. Gets the job done.”
Rated 4.8 out of 5 across 360+ Upwork jobs since 2010, on our company and founder profiles.See them on Upwork
Our plugin customers rate us 4.8 on Trustpilot (93 reviews).Read them
Want to see the code review process in practice?
Customer engineers can read every PR comment from day one. Discovery call is free.
WBComDesigns is amazing. The WP plugins and themes are of top notch quality with lots of features and updated very frequently. Supports are very responsive and helpful. I use Reign with TutorLMS, and the experience is surprisingly smooth.…