Thank you to everyone who participated in the discussion a few months ago about how this team should address issues that are discovered with themes that are live in the directory!
It’s great when people are willing to share their thoughts about the ideal or preferred way to resolve problems, because it helps the team understand what theme authors expect and prefer — which helps reviewers design a process that is less surprising for theme authors.
The purpose of this post is to gather feedback on a proposal for how this team should address issues found in themes that are already live in the directory.
All feedback is welcome, but in particular, it would be helpful to know:
- Are there any parts of this process that might be unclear or confusing?
- Does the process seem too strict, too permissive, or just about right?
- Should anything be added to this process (keeping in mind that all reviewers are volunteers who have limited time available)?
- Does this process fail to address any significant issues or steps needed for resolution?
Resolving low- to moderate-impact issues
Some examples of low-impact or moderate-impact issues are:
- Screenshot issues
- Overuse of content creation in customizer
- Plugin functionality type features
- Demo content import
- Failing to meet expectations/guidelines which were added more than 6 months ago
- Recommending plugins without reason or good integration in the theme
Resolution process:
When a theme reviewer notices that a live theme does not match the theme guidelines, a theme author should expect the following steps:
- The theme author will be emailed with an explanation of the issue(s) and a request to resolve them. The email will include a deadline for the requested changes, which will allow the author at least 7 days to submit changes, and a link to a page with information about the resolution process.
- If the changes are submitted before the deadline, then
- they will be reviewed and approved, or
- the author will be informed of additional changes that must be made.
- If changes that resolve the issue are not submitted on time, then the theme may be “delisted” until the issues are resolved.
- Once the theme is delisted, if the theme author does not submit changes that resolve the problem within 3 months, the theme will be suspended until the changes have been resolved.
Resolving high-impact issues
Some examples of high-impact issues are:
- License issues
- Security issues
- User tracking-related issues
- User Consent Issues
- Advertising, promoting or otherwise endorsing any real products and/or services on the front (except the theme credit link)
- PHP Fatal Errors* (If a theme is found to throw fatal errors on activation, it is not compatible with modern (PHP 7+) or they are not compatible with the most recent versions of WP.)
Resolution process:
*If a theme is found to have PHP errors, it will immediately be suspended until the author uploads fixes. (This is to prevent the theme previewer error logs being cluttered and to prevent new users running into the issue.)
When a theme reviewer notices a high-impact issue in a live theme, a theme author should expect the following steps:
- The theme author will be emailed with an explanation of the issue(s) and a request to resolve them. The email will also include:
- A deadline for the requested changes, which will allow the author at least 3 days to submit changes.
- An explanation of what will happen if the changes are not submitted in time, or if the changes don’t solve the issue(s).
- If the changes are submitted before the deadline, then
- they will be reviewed and approved, or
- the author will be informed of additional changes that must be made.
- If changes that resolve the issue are not submitted on time, then the theme will be “delisted” or suspended until the issues are resolved.
- Once the theme is delisted, if the theme author does not submit changes that resolve the problem within 3 months, the theme will be suspended until the changes have been resolved.
Repeated Issues
In the case of a theme author who demonstrates a pattern of failing to meet theme directory expectations when updating themes — for example, by breaking a certain guideline repeatedly after correcting it in the past, or by breaking different guidelines repeatedly in a period of 3-12 months, then all of the author’s themes may be suspended from the directory, permanently. The author may appeal this decision with the Executive Director (Josepha Haden Chomphosy) or Project Lead (Matt Mullenweg).
Exceptions
Sometimes special cases will be discovered, which can’t be resolved by the processes described above. Those should be rare, but might include the following situations:
- A theme passed the initial review and was added to the directory but should not have been added because it is a clone, or for other foundational reasons. In this case, the theme will be suspended immediately and the author will be warned that another attempt to submit a cloned theme to the directory will result in a lifetime ban.
Delisting as mentioned in the post, relies on the delisting option being implemented.
The feedback period will be open until December 7th, to allow the team representatives time to summarize it for the December 8 biweekly meeting.
At that time, the team will adjust the proposed process as seems necessary, and then publish the process in the handbook.
Thanks for your time, and for sharing your themes on WordPress.org!
#feedback,
#themes-team
Hey William,
There is some inconsistency in the text.
But then you go on to say that the author will be emailed and will have 3 days to upload a fix, otherwise the theme will be delisted or suspended.
The way I see this update is that there will be no real punishment in those cases when theme authors are active and can fix issues in the first 72 hours.
So authors can “accidentally” break a guideline or two once or twice a year without any repercussions.
Or is there something that I’m missing?
There is no punishment. The people working in the team are team representatives, not punishers 😉
😀♥️
Sure, if someone accidentally has an issue every 6-12 months they would have no direct repercussions provided they resolve the issues when asked.
If it was a persistent pattern though the final option would be invoked and the themes would be removed for repeatedly failing to meet the expectations of the directory. I hope to never have to reach this point but if we do then this policy is here to guide how it is handled.
The star ( * ) is there to mark the exception for this requirement.
Is there an example of “Overuse of content creation in customizer”? I’d like to avoid my theme Semper Fi Lite becoming labeled that.
When you are not sure it is always best to ask first, but in the ticket, with full context, descriptions and examples.
Only minor content creation is allowed. There are no set numbers. Don’t add large text sections that causes the user to loos their entire front page content when they switch themes.