Theme Topics @ Contributor Day

Future of the Theme Review process & making it smoother and faster

In this session we continued the Theme Review specific discussions from the 13th of June.

The main focus was an improved review process with a new backend.
We discussed the possible changes and differences between the current and a new system:

  • The current Themes TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. would be replaced by WordPress.
  • Reviewers will no longer be assigned to themes. This means that anyone can do a followup review. The reviewer would not need to wait for the reply and would be free to review another theme meanwhile.
  • There will no longer be a 7 day deadline for an author to reply. The theme will wait until an update is submitted.
  • The reviewer would not need to close a theme as “not approved” because of minor coding errors, only if the themes are copies, spam etc.
  • The term queue will no longer be used. Reviewers will be able to decide if they want to review the oldest theme or any other theme.
  • Communication between authors and reviewers would be through e-mail.
  • Theme authors should have access to SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/. to update their theme once it is live.
  • Parsing of the readme file: multiple authors, multiple screenshots etc.
  • There should also be standard texts for common errors, that could be added to a review.

We discussed how we can make the reviews available for anyone to read, and also where the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) review would fit in the new workflow.

Parts of the system is already in use by plugins, but it needs to be improved and completed. Once it is fully working for plugins, it will be copied over to themes. The first deadline is set to December 2017.

Another question concerned what information or feedback the theme author needs after submitting a theme. The suggestion is that instead of showing a theme’s queue position, we should show the current status (pending -awaiting review, pending -awaiting update).

Most of the points above requires the backend to be complete, but we also discussed what the Theme Review Team could do short term.

The team would need to inform theme authors about the specific format for the readme file so that it can be parsed correctly when the backend is ready. The suggested format is the current pluginPlugin A 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 readme.

We briefly discussed Theme Review requirements and the .org theme previews. It was suggested that the reviewers should allow more minor content creation and also focus more on design.

Code Automation for Themes/Plugins

  • PHPCS’s problem requires certain functions and it can’t handle that.
  • Theme Check doesn’t have unit tests, so it rewrote it.
  • Dream: Checkboxes show green, yellow or red. Showing a theme/plugin health. Some required, some not.
  • Rank according to severity of issues.
  • Some people are overwhelmed with the requirements to be a TRT volunteer.
  • Humans would still be used to help with the quality of themes, but just from more people, not just contributors.
  • Three contexts: when developing, on upload, and continuous.
  • False positives are an issue at times.
  • Could be one backend, multiple front ends.
  • TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post. errors so they’re suppressed if it’s not really an issue.
  • Local tool would help with false positives.
  • People could check in code, and when it passes, it could be made public to other people.
  • Huge opportunity for educating on best practices.
  • WordPress coding standards could be a check, but not required.
  • Plugins/Themes could include their own checks. Would need to be limited.
  • Checks could give compatibility for PHP7, etc.
  • Same check for WordPress versions. Knowing whether code generates warnings or errors would be helpful.
  • Searching for 500 errors.
  • Ticker for themes being activated WITH PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. errors.
  • This could improve directory interfaces for plugins and themes.
  • Can plugins be easily transferred. Need to know the expectations and norms. This way, plugins and themes could be more cared for.
  • Up to versions run now to tell people that’s not up to date, and it helps with updates.
  • Could be checks for mobile, etc. to push better themes to the top.
  • Probably need to start small. Up to checks and go from there.
  • Locally first, plugin, then server everywhere.
  • Reduce amount of manual checks for accessibility checks.
  • TRT is working on a lot of tools to start solving some of this.
  • Visual regression testing in themes has helped some developers.
  • Starter theme content could help with regression testing. What would be done with the differences? Users might want to know this.
  • Do the easy stuff first.