Sometimes, things need to change; that’s true for everything. The Theme Review Team is aware that we currently have problems. This post proposes some suggestions for how we should change. The objective of these changes are to reduce queues and make reviewing easier, both for those being reviewed and those doing the review.

A big thanks goes out to everyone that has helped with writing this post. Specific props to @emiluzelac, @grappleulrich, @greenshady, @samuelsidler, @cais and @jcastaneda. The admin team have signed off on this in agreement.

Our role as a team should be to check that the theme has no licensing, security, or “breaking” issues. Any issues beyond those three categories should be dealt with after the fact, not during review. We all want to do more, but without ensuring we provide the minimum review to themes in a timely manner, we aren’t succeeding.

Let’s have a look at the following sections and see how we can improve.

Structure
In order for us to function, we should change the structure of our team.

• Reduce down to 2 tiers for reviewers: key reviewers and reviewers. No more admins. If you have not been actively contributing to theme review (in either reviews or projects; more on this later) for 6 months, then your key reviewer status will be removed.
• Key reviewers can reassign tickets and have make.blog access.
• Key reviewers can delete tickets and edit comments on tickets.

Make.blog
Communication is key. As we move to two tiers, we will add in a co-review process on the make blog to ensure we are a united voice.

• No posts will be published unless two key reviewers sign off the post.
• We will update the handbook with this and posting guidelines.

Release focus
To make changes, we need to focus on specific projects.

• Projects should be linked to WordPress releases.
• Before the start of each WordPress release, the team will have a meeting to decide focus this cycle, just as the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team does.
• There will be a post at end of the cycle, listing those that contributed to a project, not only to reviews.
• Tying projects to a release cycle helps us focus on digestible pieces that can be completed quickly.
• A page will be created to list current projects and collect ideas for future projects.

Review flow
How themes are reviewed is important. We have a lot of blockages in our process to resolve.

• We should get the process as close to the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party review one as possible.
• A ticket is not assigned to one reviewer.
• The reviewer going through the queue replies to author.
• Tickets aren’t just allocated to one reviewer. Anyone can review and then pick up a ticket if reviewer doesn’t respond.
• Keep response time to 7 days for both reviewers and those being reviewed, however as with above, anyone can review.
• Tickets with no response from a reviewer after 24 hours, will be move to the “new” queue; this change makes it easier to dive in and help.

Review quality
If our theme quality isn’t looked at, the queues will get back up.

• We need to provide education into what is a good review.
• We should show example reviews for people to learn from.
• We need to promote anyone that is a good reviewer to key reviewer and shout about it.
• We all should be encouraging each other to help make reviews better, not by commenting on tickets, but by directly encouraging the reviewer.
• Our culture should be supportive, to help each other become amazing reviewers.
• By the end of year, we need to bring back mentoring. Mentoring should be something every reviewer sees as a way to help the team. All key reviewers should participate in mentoring, where possible.

Review baseline
What we review needs to change to help the queues and those reviewing.

• Requirements should be reduced to those that cause security issues or break sites: for example not using WordPress functions.
• If you find the following in a review, the review is automatically closed:
  • Multiple prefixing issues.
  • Multiple security issues.
• Other requirements will exist but be automated.

To go along with all of this above we need an initial roadmap for the next release. Here is our suggestion:

Theme check plugin rewrite

• Led by @grappleulrich.
• Move development to GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, giving access to more contributors.
• Develop the plugin using an easier base, for easier (and more!) contributions.
• Initial action plan here.

Reviewer flow

• Led by @karmatosed.
• Rework current flow to match the above proposals.
• Improve uploading flow.
• Improve reviewer flow.

Everything about is doable and doesn’t require a lot of changes, just several small important ones. That’s the important thing: the small changes combine to create a large impact.

There’s a lot to discuss, so please leave your comments below. We will discuss further during the next team meeting on Tuesday Tuesday at 18:00 UTC