Meeting notes from the 9th of July 2019

The meeting started with a quick round of updates. There is still no resolution about the trusted authors (TA) issues.
After that we started discussing the proposed meeting agendas.

The following is the recap of the meeting, you can read the meeting transcript in the slack archives (a Slack account is required).

Docs team discussion about the theme developer handbook

There was a discussion on the #docs slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel about handover of the theme developer handbook to the TRT.
The idea is to have a single responsible person from the TRT team that will take care of the developer handbook for the themes. This means updating it with new requirements and keeping it up to date in general.

It was agreed that the person in charge of the theme developer handbook will be @acalfieri, who is an experienced reviewer and has been an active member of TRT for a long time.
Of course, if there will be interested volunteers to help you can always ask in the slack channel.

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) (a11yAccessibility 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)) requirements

In the accessibility team meeting it was proposed to add some of the requirements from the themes which use accessibility-ready tag to standard themes in the repository.

The emphasis is on making the themes easier to use, especially for the people with certain types of disabilities.
The proposal included incorporating the keyboard navigation, control, skip link, and form labelling requirements from the existing accessibility-ready requirements.

This is the first step in making all themes in wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ repository accessible.

The changed requirement wouldn’t encompass all the accessibility-ready requirements to be present on the standard themes, nor would it automatically make them accessibility-ready, but by incorporating one by one requirements, through longer time period, the idea is to encourage theme authors to write accessible themes out of the box.

It was agreed that the skip links requirement from the accessibility part will be moved to the required section of the review handbook, and that the team will implement new a11y requirement every two months. This will give theme authors enough time to make their themes more accessible.

Removing Demo Content from the theme

It was already agreed with removing demo content files (xml, json or some other format) from the themes. But there needs to be alternative to that.

It was agreed that the requirement should be updated with following to make it more clear:

Importing or Downloading:


Themes are not allowed to import content to a user’s site.
Themes are not allowed to link directly to an XML, JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., ZIP, or other file for direct download or import.
Themes are not allowed to bundle demo content via an XML, JSON, ZIP, or other file.

Also, a meeting will be held in the #design slack channel about updating the wordpress.org previewer content which can then be used as a starting content for the developers to develop their themes.

Theme generated notices

All the notifications generated by a theme should use the admin_notices APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and follow the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. design pattern. They must be dismissible. Everything wrapped in the admin notice needs to follow Core UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. design for the notices.

This will be a requirement on all the themes.

Open floor discussions

There was a mention of the tool that can help reviewers review a theme – WPTRT-Cloud-Launcher. It’s a Chrome extension that launches a cloud instance that comes pre-configured with the theme and theme snifferTheme Sniffer Theme 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 the plugin directory and Github. Themes are not required to pass the Theme Sniffer scan without warnings or errors to be included in the theme directory./check plugins installed.

#meeting, #meeting-notes, #trt

Planning for keyboard navigation

The theme review team is requiring all themes to implement keyboard navigation in five weeks time, around the third of september 2019.

Because this may be a complex task for many authors, we encourage you to start planning for and working on this as soon as possible.

We want to point out that this requirement does not only include menus. All functionality should work using a keyboard only. Any action you can complete with a mouse must also be performable via keyboard.

Theme authors must provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. All controls and links must be reachable using the keyboard.

First, please read the requirement found here: https://make.wordpress.org/themes/handbook/review/accessibility/required/#keyboard-navigation

As well as the background for this requirement: Techniques for WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.0
G202: Ensuring keyboard control for all functionality

We would like to collect examples for the keyboard navigation, including menus. If you know of a good resource that is not already included, please add a comment and link.

If you need help, you can also use the Accessibility Support Forum.

As always, communication is key, if you know that you will need extra time to solve this, contact the team or add a note in your ticket so that we know that you are working on it.

Navigation menus and controls

Drop down menus and controls must be available when tabbing, using keyboard only.

Controls also include open and close buttons for modals such as off canvas sidebars or search forms.

Visible Focus

As a general rule, do not remove the browsers native outline from the focusable elements without replacing it with an accessible alternative.

Form fields

Don’t break the browsers default focus by removing the outline. Other kinds of decorative changes are also allowed. Only showing the marker inside the field is not enough.

Submit buttons

Submit buttons may be hidden during it’s normal state but visible on focus.

A high contrast color change, an outline, a border, or a text decoration change will assure that visible submit buttons pass the requirements.

Text links

Do not remove the browsers native outline without replacing it with an accessible alternative.

Make sure that you can see which link is focused. Focus should either incorporate a visual change that is not based on color (background change, underline, shape) or a color change where the difference between the two colors meets the WCAG 2.0 level AA contrast ratio (4.5:1) .

Focus order

Focus order should match the visual order. Make sure that focus doesn’t move in unexpected ways around the page.

Both forward and backwards tabbing must work. To test backwards tabbing, hold down Tab and Shift at the same time.
Please also note that use of tabindex is discouraged.

Recommended reading regarding focus order:

https://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-order

CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. grid and focus order: https://www.matuzo.at/blog/the-dark-side-of-the-grid-part-2/#visual-order

Resources

https://make.wordpress.org/accessibility/handbook/test-for-web-accessibility/test-for-web-accessibility-frontend-code/#keyboard-navigation

Example menus:

https://www.w3.org/TR/wai-aria-practices/#menu

https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

https://github.com/wpaccessibility/a11ythemepatterns

-Some concerns were voiced during our previous meeting about the above examples not being updated for 4 years, so if people would try these out and help keep the code up to date that would be very helpful.

@acalfieri Is working on an example menu here, please help her test it and leave feedback: https://github.com/anace/keyboard-navigation

https://wordpress.org/themes/twentynineteen/

https://wordpress.org/themes/twentyseventeen/

https://github.com/Automattic/_s ( https://underscores.me/ )

https://github.com/wprig/wprig/

For those interested in AMP:
https://amp-wp.org/documentation/playbooks/keyboard-accessible-navigation-menus/

Trusted Author Program – a year of its journey

Trusted authors (TA) program was started in April 2018 and it’s been more than a year of its journey. We got 56 applications in 2019, whereas we had 233 applicants in 2018. Some authors applied more than once after the rejection on the first try. Some tickets were still under review.

There was an agenda about the removal of TA program during the meeting on the 11th of June. All attendees put their own pros and cons about the TA. Since no conclusion could be made, the decision about the TA was left to the team leads. The status of TA was raised almost every meeting after that.  

After the huge discussion between leads and senior reviewers, we decided to remove the TA program from yesterday. From now on all the authors will need to follow the same queue (trac 2) again.

We know that there were some pros with TA program but still there were many cons as well. 

The team leads tried lots of different ideas and methods to make it an awesome program, but still we were unable to handle it correctly. We got lots of help from the TA authors – for which we’d like to thank them. However, there was still gaming from some of the authors – which resulted in their removal from the TA program.

One of the intentions of the TA program was to reduce the gaming by the use of multiple accounts. However we still saw some authors having multiple accounts so this intention was not realised though the program existing.

While TA members were able to have themes go live with ease and regularity the normal queue for other authors was not in a good situation. The wait time was growing longer and the admin queue was getting out of hand. In an effort to make the queue shorter and allow the admin queue to be cleared we tried to enlist the help from TA authors by having them review themes in order to stay in the program.

We strongly believed that TA members were highly familiar with the requirements but we found that was not the case for all of them. Additionally some authors did not feel confident enough in their own understanding of all requirements to perform reviews and set themes live. Instead many TA reviews went to admin queue after approval. This was an indicator that the quality of the themes by TA may not be as high as expected.

Whenever we had time, we used it to review the TA tickets. We saw non-GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. image sources, validation and translation issues. These are similar types of things that are flagged in many reviews but we never expected such things from the TA authors.

With the ability to releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. themes frequently, and go live without much friction, some authors started to struggle to maintain quality on that more regular schedule. Over time clone themes became common. Themes with minor or insignificant changes – like slight color tweaks or font swaps – were frequently what was submitted. Spotting these after they were live and reacting to them has proved to be inefficient and ineffective to deter them. These kinds of clone themes give no real value to end users.

Child themes with very minimal changes also become so common that authors were requested to indicate what changes they were making in their tickets so that reviewers could judge if the changes were too small to justify a whole new theme without needing to go through a potentially lengthy review to reach that conclusion. Sadly the call was made too many times that the changes did not justify the new theme.

Due to all this the TA program is shut down. All authors will be treated the same.

All the themes will be reviewed from the top of the queue and themes will get closed with 3+ distinct issues. One theme at a time and max one per month rule is still there. 

Reviewers can check theme anywhere from the queue, but the themes should be assigned from only the top of the queue. Your theme can get closed from any position – even from the approved queue – so you need to know the guidelines properly and need to follow them.

If you have themes in the repository, you need to follow all the existing and added guidelines. There will be some limited time for implementing new guidelines and in that time frame you need to update your theme.

All the other requirements are the same and the review process is the same as before.

#decision, #trt, #trusted-authors

Meeting notes from August 13th, 2019

A meeting was held with the proposed agenda.

The following is the recap of the meeting, you can read the meeting transcript in the slack archives (a Slack account is required).

Weekly Updates

Some authors asked their themes to be closed, which was done. If you need your existing tickets closed you can pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” the leads.

In the past seven days:

  • 246 tickets were opened
  • 233 tickets were closed
  • 103 new tickets are waiting for review
  • 4 tickets are older than 4 weeks
  • 53 tickets are older than 2 weeks
  • 76 tickets are older than 1 week
  • 97 tickets are older than 3 days

Trusted Authors (TA) announcement

From today, the TA program is closed.

The program did not fulfil the intended plan and has ultimately caused more problems than solving.

Some reasons for removal of the program include:

  • Entry criteria was difficult to set, it was hard to maintain consistency.
  • Management of the queue required separate reports in tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. to be modified via SQL – that was unsustainable.
  • Being TA has benefits unavailable for other authors – how fair this is for everyone has been commented on a loads of times. 

The leads will make a blog post describing the reasoning behind removal of the TA program.

Open floor

A discussion was held about the removal of the TA. One issue that came up during the discussion, was the fairness of the admin queue. And of the review process in general, since some authors may get an experienced reviewer, and others may get a novice reviewer, which will require another inspection to see if they did a good job.

There were proposals to fix these issues, such as pairing new with experienced reviewers.

#meeting, #meeting-notes, #trt

Theme Review Team Meeting Agenda for August 13, 2019

Theme review team conducts a meeting on the second and fourth Tuesday of the month. We usually have fixed agendas for the fourth Tuesday meeting. But we have some agenda to discuss on this second Tuesday as well.

We encourage all members and anyone interested to attend.

Channel: #themereview | Time: Tuesday, 13th August 2019, 17:00 UTC

Agenda for Discussion

  1. Weekly Updates
  2. Announcement from team leads about the trusted authors (TA) status
  3. Open floor.

Meetings usually last around 60 minutes. If anyone wants anything else to add on the existing agenda comment below and we will try to fit it in.

Discussion can be held in the comments below.

#agenda

#agenda