WordPress Executive Director Josepha Haden Chomphosy on Wednesday released next steps for themes and reviews for the official theme directory. In the article, she describes the tools and types of access that the Themes team needs. She also defined other goals for the system. The timeline is to have much of that in place by early 2022.
Two months ago, things turned to the head. Project manager Matt Mullenweg saw a lot of what we all saw. Creative contributions to the free directory were scarce, with most submissions being simply “light” themes stripped down with business interests.
There was disagreement on Why the directory did not produce the high quality projects that users would expect from an official source. Mullenweg cited the rules and the update mechanism as problems.
However, others like Joost de Valk, the CPO for Yoast, said the reality of the situation is that money is now part of the equation. Producing, maintaining and supporting high quality products is not sustainable without the financial resources in place. Because WordPress.org doesn’t provide any way for developers to make money directly, upselling motivated themes are the result. Eric Karkovack elaborated on this in his article for Speckyboy, Are Free High Quality WordPress Themes a Thing of the Past?
Some members of the Theme Team disagreed that the rules were the problem. At the heart of the team’s manual is the idea that themes should be GPL-compliant, 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 faster through the directory. The goal is to be a bit more like the plugin directory and let users guide others through the star rating system.
However, themes and plugins are different beasts. Themes must follow certain standard patterns and do specific things to actually work. The best way to do this is by using automated tools doing the hard work humans have been doing over the past decade. Many directives can become a line of code in a script. Each new line would lighten the burden on volunteers.
The Theme Team agreed with their assessment of the quality of the theme. However, some felt that the theme system was the oft-forgotten stepson that received all the discounts from its favorite brother, the plugin directory. They needed the resources of the community to drive any kind of change. Team members had little power outside of their access control responsibilities and lacked volunteers.
Changing hearts and minds
Haden Chomphosy posted notes on the February meeting. The post detailed the ideas and what happened. However, much of it seemed vague in terms of what could be actionable. It was the preparation phase.
In a private chat with one of the Theme Team representatives, they said the meeting was productive not because of the action going on, but because of the change in perspective. More and more representatives of the team accepted 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 change in perspective didn’t mean to be cautious and flip the switch overnight. The team wanted to put security barriers in place, especially when it came to high priority issues such as appropriate licensing.
“At the meeting, we discussed the need to change the review process,” said team representative Ari Stathopoulos. “All guidelines have a reason why they exist. They were all added after some things were abused. But the process followed had an unfortunate side effect; the rules that were added to prevent the abuse of a few bad apples are the same rules that hinder innovation and deter people from submitting a theme to the repository. “
He spoke of the universal rules of not doing bad things, disrespecting others or abusing the system. By 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 little more wordy may be needed but obviously not as wordy as the dozens and dozens of guidelines. that we currently have. “
The next steps: tools and a user-centric strategy
The first objective is to have access to a functional meta-environment for testing. One of the team reps currently has it. However, others would need long-term access. Moderator tools are also on the reviewer list, probably similar to the plugin review team.
These are some of the basic things. The next element will be more automation. Dion Hulse is currently working on automated security checks, which should help resolve an ongoing issue. Steve Dufresne is working on an automated code scanning solution.
One idea for a post-commit strategy is to flag topics with “quality tags”. These include things like Gutenberg-ready, security, latest update, translation-ready, and accessibility. It is not known how this system would work, but it could be a way to bring up themes in the repertoire that meet the standards. Maybe a new Featured Theme algorithm should be in the works?
The last element of the proposal introduces the concept of a yes / no voting mechanism for end users. These would be “trusted tags” that allowed users to mark themes as updated, visually broken, etc. The goal is to give much of the responsibility for controlling access to users, putting them in control of whatever they want in the theme directory.