Theme Review Process #

Every theme that is uploaded for inclusion in the repo goes through this process:

  1. A theme gets uploaded.
  2. A theme goes to the new theme queue.
  3. A theme gets allocated a theme reviewer.
  4. The reviewer does a review checking the required items and noting any recommendations.
  5. Once the review is done the review is added to the theme ticket.
  6. A committer reviews that ticket.
  7. If all the required items aren’t met, the theme should not be approved and left open for updates.
  8. If a theme ticket has no update from the theme author for 7 days it will be closed due to inactivity.
  9. If a theme ticket has no update from the theme reviewer for 7 days it will be allocated to a new reviewer.
  10. Once a theme passes all required checks, the theme is approved to go live.
  11. Once a theme is approved to go live one of the committers will review the ticket and make it live.
  12. If issues are found during the review, the ticket will be updated and the theme author and reviewer asked to continue the review.
  13. Once a ticket has been marked live it shows up on the repo and all updates to it from then on are done in the update queue.

Top ↑

Timeframes #

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.

Top ↑

The Review #

Required #

There are certain checks that all themes need to pass before they can be put on the theme repository. You can find all the required items here.

Top ↑

Along with the required items there are a range of things recommended as good practice for themes. You can find all the recommended items here.

Top ↑

Notes #

Reviewers are encouraged to add extra information. For example commenting on design or Sass recommendations. We include these as guides in this handbook only. As both are subjective, for now these are merely suggested best practices.

You can read more about workflows here for reviews.

Top ↑

Case by case #

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.