Currently, all requirements are listed on one page:
https://make.wordpress.org/themes/handbook/review/required/
With the exception of requirements from Theme Check, which are listed here:
https://make.wordpress.org/themes/handbook/review/required/theme-check-plugin/

Current presentation
The requirements are divided into the following sections:

• Accessibility
• Code
• Core Functionality and Features
• Child themes
• Readme.txt file
• Presentation vs Functionality
• Importing or Downloading
• Documentation
• Language
• Licensing
• Naming
• Options and Settings
• Plugins
• Screenshot
• Privacy
• Image guidelines
• Selling, credits, and links
• Stylesheets and Scripts
• Templates

-It can be difficult to find the requirement if it is not listed in the section you expect it to be in.
Are there any benefits of sorting them by priority instead of in sections?
Should we separate code quality from license and upselling?
-Right now, it is a mix of what you can't do with code, what you can't do on your own website,
and what you can't do with your account.

Discoverability of the examples
Some requirements have examples.
Users still find it hard to find the example they are looking for.

• These were moved from a separate page into the requirements
  page because very few people could find the examples page.

• The examples only show when you use the example toggle.
  We decided to hide the examples because we thought the requirements
  page would be to big if the examples were visible at all times.
  But this means that the text is hidden from the on-page search.

Currently, image guidelines, screenshot requirements and requirements for placeholder images are
in 3 separate pages.

Suggested solution is to place all image requirements under one section.

The purpose of this issue is to place information about all existing requirements in one document.

1. Collect the information
2. Requirements that should be reduced to recommendations will be removed from the list and placed in #11
3. Publish a proposal with the new, remaining requirements on the make blog.

Theme Review action

https://github.com/WordPress/theme-review-action

Theme Check

https://github.com/WordPress/theme-check

This issue hopes to inform #12 by identifying the current logic that processes theme uploads.

Summary

The project receives the zip file and proceeds to ask questions about the theme and the account, runs the Theme check plugin, sets up svn, creates a trac ticket, and informs the user of their submission.

Questions

Any failures to these questions will result in an error message being thrown and the upload stops.

Ref: https://github.com/WordPress/wordpress.org/blob/master/wordpress.org/public_html/wp-content/plugins/theme-directory/class-wporg-themes-upload.php

• Is the zip file empty?
• Does style.css exist?
• Does a screenshot exist?
• Does the theme have a name?
• Does the name not include "WordPress"?
• Does the name not include "Theme"?
• Does the name not include a reserved word?
• Does it have a description?
• Does it have Tags?
• Does it have a Version?
  • Is the version newer than the current one?
• Are Theme URI & Author URI not the same? (conditional)
• Does it have a parent theme? (conditional)
• Does the theme already exist?
• Is the Theme URI already in use?
• Is the theme suspended?

Purpose

This issue is a proposal on how we could structure the technical aspects of the theme review process to converge on a collection of tools, new & existing.

The theme review process and it's associated infrastructure spreads out across numerous domains and includes different projects created in different languages. Rule sets are enforced linearly across the system making it difficult to identify gaps, add/modify rules or incorporate new tools.

The temptation when trying to automate an existing process is to rush into adding more rules to existing tools, but at this point, I think it would be more helpful to separate out the high-level concerns, solidify their rules sets and then assign the right tools. Some of the challenges are new and choosing the right tool for the specific job will be critical in this project's success.

For context, please read:

• Meeting Notes | Matt, Josepha, and Theme Team
• Next Steps on Themes and Reviews

Table Of Contents

• Technical Flow Chart
• Parts
  • Upload Interface
  • System Checks
  • Structure Checks
  • Basic Distribution Checks
  • Static Code Review
  • User Experience Review
  • Review Results Interface
• Next Steps

Technical Flow Chart #

Parts #

The parts following represent a general responsibility.

Upload Interface #

Users currently upload their themes via the interface on WordPress.org. The interface provides some basic error messaging when themes have "upload critical" errors.

Default	Error view

System Checks #

This is a collection of checks to make sure that the theme can be added to the directory. At a high level, the rules will make sure the theme is unique to the directory and follows the correct naming conventions. It will also make sure that the user is authorized to upload a theme.

See rule list

Structure Checks #

This is a collection of checks to make sure that the theme has the necessary files in the correct format for the theme type.

See rule list

Basic Distribution Checks #

This is a collection of checks that make sure the theme can be distributed based on proper licensing and the absence of overtly abusive structure/content.

See rule list

Static Code Review #

This is a diverse collection of checks that work on static code.

See rule list

User Experience Review #

The is a collection of checks that utilize a browser session to review a theme's user experience.

See rule list

Review Results Interface #

The theme review interface is currently a ticket on themes.trac.wordpress.org. Each theme gets a ticket and all output from the tests are presented to the uploadee.

Example Results

Next Steps #

• Agree on the parts
• Associate the correct tools to the correct parts
• Assign rules to the correct tools
• Identify which rules are completed (Not, Partially, Full).
• Write the remaining tests.

Appendix #

These were gathered from this theme requirements issue and are subject to change. Additionally, this issue is not the source of truth and any questions or comments about specific rules should be added to the aforementioned issue.

System Check List #

Basic Distribution Check List #

Structure Check List #

Static Code and User Experience Review rules #

There rules are categorized to into Safe, Global and Quality in order to make them more digestible. For this moment in time, they are internal.

Safe

These rules indicate whether the theme is safe to install.

Global

These rules indicate whether the theme is ready for a global user base.

Quality

These rules indicate whether the theme is of minimum quality.

The coding standards group proposed working on RFCs when adding requirements. Unfortunately, this didn't take, but we can maybe use parts of their workflow and adapt them to our own.

https://github.com/WordPress-Coding-Standards/rfcs

I'd like to have a template when opening a PR or an issue with the proposals so that whenever people want to add a change it follows some similar structure.

Section: Images

Requirement:
There should not be a default logo.

Explanation:
The theme should not be used to advertise the theme brand or the theme authors brand on the front when the theme is installed.

The custom logo option does not have a setting for a default image. Instead, authors often add a fallback that is visible when the user has not uploaded a logo of their own.
This means that it is not possible for users to remove the logo without replacing it.

The requirements page could include a note that explains that child themes can only be included if the parent theme is in the directory (This is a frequently asked question).

It has been a while since this repository was used.
If we want to reuse it for the upcoming requirement changes, we should first make sure it matches the requirements page