I’d like the WordPress review process to make a clearer distinction between requirements and recommendations.

An Important Distinction

I think it might help to think about review in two categories:

Guardrails protect users from concrete harm:

  • Security vulnerabilities
  • Malicious code
  • Broken core functionality
  • Accessibility issues that prevent users from accessing content
  • Performance problems that crash sites

Guidelines help improve quality:

  • Design patterns we’ve found effective
  • Code organization approaches
  • Common practices that tend to work well
  • Stylistic recommendations

Both absolutely have value. My question is whether we’ve clearly defined which is which, and whether that clarity shows up consistently in the review process.

Where reviews get stuck

Sometimes review feedback rejects an unfamiliar approach even when it works and doesn’t harm users. That seems more like a preference than a requirement.

I wonder if we could be clearer about distinguishing between “this could harm users” and “we typically recommend this other approach.”

Recognizing the work involved

I want to be really clear: I deeply respect the volunteers who do review work. You put in countless hours making WordPress better.

And developers do too. We pour our time into creating themes and plugins we believe will help people.

Reviewers and developers are both volunteering to improve WordPress. I’d like a process that maintains standards and allows different ways to meet them.

What I’d change

Could reviews enforce the rules that protect users and present the rest as advice?

What if reviewers ran automated checks, verified security and functionality, and then offered recommendations for improvement that developers could choose to implement?

I’m not suggesting we lower standards. I’m asking if we might separate “must fix” from “you might consider.”

How to try it

I don’t have all the answers. What I’m hoping for is a conversation about whether our current process serves its intended purpose as well as it could.

If we collectively decide that enforcing design consistency is part of the mission, let’s say that explicitly and discuss whether that’s what we want.

I’d like to discuss how reviews could focus on safety while allowing different implementations.

That would give developers more room to solve problems their own way.

What are your thoughts?