On Wednesday, WordPress executive director Josepha Haden Chomphosy posted the next steps forward for themes and reviews for the official theme directory. In the post, she describes the tools and types of access the Themes Team needs. She also laid out some other goals for the system. The timeline is to have much of this in place by early 2022.
Two months ago, things were coming to a head. Project lead Matt Mullenweg saw much of what we have all been seeing. Creative contributions to the free directory were few and far between, many of the submissions merely being stripped-down “lite” themes with commercial interests.
There was some disagreement on why the directory was not producing the high-quality projects users should expect from an official source. Mullenweg cited the rules and update mechanism as problem areas.
However, others like Joost de Valk, the CPO of Yoast, said the reality of the situation is that money is now a part of the equation. Producing high-quality products, maintaining them, and supporting them is not sustainable without the financial resources in place. Because WordPress.org provides no path for developers to make money directly, upsell-motived themes are the result. Eric Karkovack expanded upon this in his piece for Speckyboy, Are High-Quality Free WordPress Themes a Thing of the Past?
Some of the Themes Team members disagreed that the rules were the problem. At the heart of the team’s handbook is the idea that themes should be GPL-compatible, secure, and not break things.
The problem is not necessarily specific guidelines but the process. Mullenweg wanted to switch to a post-commit strategy that would see themes move into the directory more quickly. The goal is to be a little more like the plugin directory and let users guide others through the star-rating review system.
However, themes and plugins are different beasts. Themes must follow some standard patterns and do some specific things to actually work. The best way to make that happen is with automated tools performing the grunt work that humans have been doing for the past decade. Many guidelines could become a line of code in a script. Each new line would lighten the burden on volunteers.
The Themes Team agreed with his assessment of the theme quality. However, some did feel like the theme system was the oft-forgotten stepchild who received all the hand-me-downs from its preferred sibling, the plugin directory. They needed resources from the community to drive any sort of change. Team members had little power outside of their gatekeeping responsibilities and were short on volunteers.
Changing Hearts and Minds
Haden Chomphosy published notes on the meeting in February. The post detailed the ideas and what took place. However, much of it seemed vague in terms of actionable items. It was the groundwork phase.
In a private discussion with one of the Themes Team reps, they said the meeting was productive not because of action taking place but through the changing of outlooks. More of the team reps warmed to the idea of reducing the requirements and moving forward with a change. The meeting was more about winning hearts and minds, which was a necessary first step.
This changed outlook did not mean throwing caution to the wind and flipping the switch overnight. The team wanted to set some guardrails in place, particularly surrounding high-priority issues like proper licensing.
“In the meeting, we discussed the need to change the review process,” said team rep Ari Stathopoulos. “All guidelines have a reason they exist. They were all added after some things got abused. But the process followed had an unfortunate side-effect; the rules that were added to avoid abuse by a few bad apples are the same rules that hinder innovation and deter people from submitting a theme in the repository.”
He brought up the universal rules of not doing evil things, disrespecting others, or abusing the system. Citing them as the foundation of what the guidelines should be. “But then, of course, everyone has a different definition of evil, disrespect, and abuse, so something a bit more verbose may be needed but obviously not as verbose as the dozens upon dozens of guidelines we currently have.”
The Next Steps: Tools and a User-First Strategy
The first goal is to have access to a functional meta environment for testing. One of the team reps currently has this. However, others would need access in the long term. Moderator tools are also on the list for reviewers, likely similar to what the Plugin Review Team has.
Those are some of the baseline things. The next item will be more automation. Dion Hulse is currently working on automated security checks, which should help with a consistent problem area. Steve Dufresne is working on an automated code-scanning solution.
One idea for a post-commit strategy is flagging themes with “quality tags.” These include items like Gutenberg-ready, security, last updated, translation-ready, and accessibility. It is not clear how this system would work, but it could be a way to surface themes in the directory that meet standards. Perhaps a new featured-theme algorithm should be in the works?
The last piece of the proposal introduces the concept of a yes/no voting mechanism for end-users. These would be “trust tags” that allowed users to mark themes as updated, visually broken, and more. The goal is to hand over much of the gatekeeping responsibility to users, putting them in the driver’s seat of what they want out of the theme directory.