Code review and release restrictions

Who reviews what, who is allowed to release, and the bar a PR must clear to merge

• All teams will handle code reviews and releases internally for any repositories they are responsible for.
• All teams can request a code review from the WordPress COE team at any time.
• All teams are expected to request an architectural review from the WordPress COE team in the early stages of any new development.
• All code merged into the develop branch of any repository must be done as a pull request which is to be reviewed by at least one other member from the same team.
• All releases on the main branch for brand plugins must be handled by the WordPress COE team.
• All releases on the main branch for modules must be handled by the team that owns the module.
• All pre-releases on the develop, release/*, or hotfix/* branches can be done by anyone on any repository as long as the proper conventions are followed.
• Tests should be written for all new code, or updated for existing code, by the team developing the functionality or making the change.

Merge bar

No pull requests are to be merged until it has:

• At least one code review
• All tests pass
• Linting passes
• Tests are written for any new features or code changes

Tagging conventions and what each version number means are covered in Releases and versioning.

Related

• Git and branching

  GitFlow, branch naming, and what CI runs at each stage

• Releases and versioning

  Release cadence, semantic versioning, and the tags each branch type may carry

• Architectural review

  What an architectural review covers and what to prepare before requesting one

• Release runbook

  The step by step a release lead follows, from Jira planning to posting in Teams