What about single-developer projects?

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.

Do you allow self-merge?

No. Self-merge bypasses the two-reviewer rule. Branch protection on production branches blocks self-merge at the GitHub level.

What if a reviewer is unavailable?

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.

How do you handle hotfixes?

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.

What is the WPCS, PHPStan, lint setup?

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.

Process Code review

Two-reviewer rule on every production branch.

Two human reviewers on every PR to main. Automated CI gates before review. Branch protection enforces the rule at the GitHub level. No exceptions.

Start a project See development sprints

Branch protection enforces the rule, not policy alone

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.

Engineer opens PR

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.

Automated CI runs

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.

First reviewer reads

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.

Second reviewer for production branches

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.

Author addresses feedback

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.

Merge and deploy

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.

What CI gates check

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.

What human reviewers check

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.

Security review for customer-facing changes

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.

What we do not do

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.

What about single-developer projects?

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.
Do you allow self-merge?

No. Self-merge bypasses the two-reviewer rule. Branch protection on production branches blocks self-merge at the GitHub level.
What if a reviewer is unavailable?

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.
How do you handle hotfixes?

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.
What is the WPCS, PHPStan, lint setup?

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.

Want to see the code review process in practice?

Tell us about your project.

Customer engineers can read every PR comment from day one. Discovery call is free.

Start a project See handover process