We are a group of volunteers who review and approve themes submitted to be included in the official WordPress Theme directory.
We do license, security, and code quality reviews.
We help build and maintain default themes.
The primary focus of the team is to help theme authors transition to blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based themes.
November 26th is the 4th Tuesday of the month. The Theme Review Team (TRT) has a meeting at 17:00 UTC. We encourage all members and anyone interested to attend.
We usually have a fixed agenda to discuss. However, this week we don’t have anything special to discuss with the team. So we would like to request all members to comment below if you want to discuss any theme-related topics.
We will start our meeting with the updates that happened since the last meeting and what TRT leads are doing and working on. After that, we will go through the proposed topics and the meeting will end with the open floor where we can discuss various theme-related topics.
Meetings usually last around 60 minutes. Attend and share your valuable feedback and suggestions.
This meeting we had an announcement about the new team structure as well as discussions about the future and the team’s purpose.
Team no longer has leads – the team now has respresentatives and it is a flat team structure with loosely defined roles and responsibilities where individuals can contribute in ways that they feel strongly about.
There were discussions about what the Theme Review team’s purpose was. It is important to have a single collective goal and vision so that everyone is helping to reach it. A possible statement that felt fitting was:
To ensure best practices are followed in themes and that guidelines exist to prevent bad things being a problem users need to face themselves.
Triage, as described in the test handbook, is a process of sorting, labeling, and closing issues on the TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. or GithubGitHubGitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. In the context of the Theme Review Team (TRT), the triage encompasses several things:
Since we didn’t have a triage in TRT for a long time (or ever?), the first meeting will just focus on going through the issues, closing the ones that can be closed and prioritizing other issues. If the time allows we’ll try to assign a champion to the issues with the highest priority. Some tickets/issues already have priority on them, but we need to see if these priorities need to be changed.
We’ll have one triage meeting in a month (for start) so that we have enough time to actually work on the issues (seeing how most of us volunteer and can work on these issues in our free time).
Championing the ticket/issue/PR/patch
Championing means being the person who is responsible for seeing that the issue is worked on. Ideally, champions are people who have some coding knowledge and can work on the issues. But they can also be people who are good at managing a project and finding people willing to work on the issue and seeing the issue is resolved within a sensible time frame.
For the metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. tickets, we need people who are comfortable with working on the meta repository alongside meta contributors. For some of these issues, we depend on the meta team who can change how things work on the theme directory. Other issues should have either a good proposal with a clear way of solving them or need input from the meta team. Hopefully, once we show some initiative on them we’ll have good feedback and will be able to sort them out.
For the WPThemeReview and Theme SnifferTheme SnifferTheme Sniffer is a plugin utilizing custom sniffs for PHP_CodeSniffer that statically analyzes your theme and ensures that it adheres to WordPress coding conventions, as well as checking your code against PHP version compatibility.
The plugin is available from GitHub.
Themes are not required to pass the Theme Sniffer scan without warnings or errors to be included in the theme directory. issues, we need people who will work on providing code examples (in the case of the standards) or are willing to learn how to write sniffssniffA module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. and how to fix issues on the Theme Sniffer pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. We also need to reach some conclusion on the open issues in the coding standards so that sniffs can be written for them. Once we have the prioritization fixed we can schedule additional meetings for discussion on working on these projects (I’ll be happy to have a meeting for people who are interested in helping out).
I’ve put the Theme Check issues as optional because we don’t have access to this repo and so far the response on accepting the PRs have been a bit low. We can prioritize issues and PRs we’d like to have implemented but unfortunately, we are dependant on one person that can act on this.
I’ve created an google docs sheet that is used as a reference for the meta related issues. Issues form the other projects will be added as the time passes so that we have it in one place and can reference it in the next triage meeting.