We have a project meeting twice a month on Tuesday at 17:00 UTC in the #themereview channel on Slack. Second Tuesday in the month is open floor and the fourth Tuesday is with a fixed agenda. Tuesday at 17:00 UTC.
We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.
Once the review is done the review is added to the theme ticket.
If all the required items aren’t met, the theme should not be approved and left open in reviewing status for updates.
If a theme ticket has no update from the theme author for 7 days it may be closed due to inactivity.
If a theme ticket has no update from the theme reviewer within the first 48 hours after assignment, the author can request that the theme is returned to the queue.
Once a theme passes all required checks, the reviewer marks the theme as approved.
Once a theme is approved the ticket will move to a new queue where a key reviewer will do the final review.
If issues are found during the final review, the ticket will be reopened and the theme author and reviewer asked to continue the review.
When no issues are found the ticket is marked live and the theme shows up on the WordPress.org repo and all updates to it from then on are done in the update queue.
There are no exact time frames for the queues. In short, the more people we have reviewing, the shorter the queues – you can find out more about becoming a reviewer here.
Allocated tickets without a response from either the theme author or reviewer within 7 days will be closed or reallocated to a new reviewer. Even if you just update to say you will be unable to take action for a few days, it’s important to keep communicating in tickets.
There are certain checks that all themes need to pass before they can be put on the WordPress.org theme repository. You can find all the required items here.
Reviewers are encouraged to add extra information. For example commenting on design recommendations. We include these as guides in this handbook only. As both are subjective, for now these are merely suggested best practices.
In some instances themes need consideration apart from the requirements. Where this is the case, one of the committers will review in addition to a reviewer. An example of this may be a licensing issue or possible cloning instance.
