I’ve been thinking a lot about the WordPress review process lately, and I want to share some thoughts in a spirit of genuine collaboration. This comes from a place of wanting to make things better for everyone involved.

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 I See Friction

Sometimes during review, feedback comes in that isn’t about safety or functionality—it’s about preference. A different but equally valid approach to solving a problem gets flagged, not because it’s harmful, but because it’s unfamiliar.

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

Honoring Everyone’s Contribution

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.

I think we’re all volunteering toward the same goal. Which is why I’m curious about how we might evolve the process to honor both perspectives—maintaining high standards while allowing room for different creative approaches.

A Question Worth Exploring

What if review focused primarily on guardrails—the things that genuinely protect users—and offered guidelines as exactly that: guidance?

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.”

Moving This Conversation Forward

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.

If we decide that review should focus on safety while encouraging diversity in implementation, let’s talk about what that looks like.

I raise this not as criticism, but as an invitation to reflect together on whether we’re solving the problem we set out to solve—and whether there might be ways to do it even better.

What are your thoughts?