Meeting notes from September 10th, 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).

Updates

In the past seven days:

  • 399 tickets were opened
  • 374 tickets were closed:
    • 357 tickets were made live
      • 7 new Themes were made live
      • 350 Theme updates were made live
      • 5 more were approved but are waiting to be made live
    • 17 tickets were not-approved
    • 0 tickets were closed-newer-version-uploaded

Proposal: Revive monthly review shindigs

@djrmom Suggested that we revive the monthly review shindigs (https://make.wordpress.org/themes/2016/12/05/december-shindig-recap/)

For those who don’t know:

Every first weekend of the month we do a queue push where we try to review as many themes as we can. Please keep in mind that it is not just about numbers but we want to focus on quality reviews as well so don’t feel like you have to do 10 themes over the weekend.

Jose Castaneda (https://make.wordpress.org/themes/2016/11/04/november-review-shindig/)

It was agreed that we should schedule it, and see how it works.

Plan for the next team leads

@joyously wanted to know when was the last time since new leads were elected. Current team lead @williampatton had an announcement that we’ll share here

I have been acting as lead and dealing with various duties for a long time. An awful lot longer than I ever expected.

This month marks the 18 month point. Originally the intention was that a term should last 6 months only.

With uncertainty about what GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ would hold and the future for themes I felt lead transitions would be highly disruptive and I wanted to avoid that. Perhaps it was not my place to make such a decision however I have done what I thought best at all times.

There will never be a perfect time to do lead transitions and with that being said: now is as good a time as any.

Please think about who you want to be leading TRT going forward and decide how best to guide them the direction the Team wants to go in. As is always the case I am available through transition to assist where that may be needed or useful. I’m not going anywhere, just stepping aside to let someone else have their turn.

Let’s try to have the transition process underway by the end of this month at the latest.

For me now is the right time for 2 reasons.

1. First and foremost it is time for someone else to have a turn at this. Being a team lead has been an incredibly rewarding experience which has allowed me to grow as a developer and feel like a very welcome part of our amazing WordPress community. Someone else deserves to be able to have that experience as well.
2. Secondly, I cannot guarantee availability as-and-when needed in the same way that I used to be able to. The more limited time I have here I want to be able to spend on things other than admin or management tasks. I have projects in mind I want to pursue but have not had the time to do it.

William Patton

It was proposed that an election for the new position is held. Anybody that is interested should directly message @kafleg, he will consult with the senior and key reviewers and will try to sort out the list of names for the election.

William mentioned that he would like to have a Theme Review Team reps instead of leads.
There are many people here with lots of various skills but have issues with the time commitment. Nobody really has a guarantee on how much time they can manage.

@poena mentioned that reps should be people who know what they do best and do that.

In the end, it was decided that a list of possible rep roles will be made and proposed rep leads in those areas.

Some questions remained unanswered and will be covered in the next meeting, such as a decision about ‘starter themes’ in the repo, impact of skip links and keyboard navigation requirements and the existing themes in the repo.

Triage meeting reminder

And in the end a small reminder about the Theme Review Triage meeting that will be held tomorrow.

#meeting, #meeting-notes, #trt

Theme review team triage meeting

Triage, as described in the test handbook, is a process of sorting, labeling, and closing issues on the TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. or GithubGitHub GitHub 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:

The idea is to go through the tickets/issues and see which can be closed, change the priority (if needed), and finding ‘champions’ who will be responsible for handling the issues.

The first meeting will be held on the #themereview 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 on Wednesday, 11th September 2019, at 17:00 UTC

Triage workflow

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 metaMeta Meta 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 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. 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 sniffs and how to fix issues on the Theme Sniffer 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.
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.

Resources

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.

Triage sheet

Contributing to WPThemeReview

Contributing to Theme Sniffer

#announcements, #triage

Meeting notes from August 27th, 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).

Updates

In the past seven days:

  • 284 tickets were opened
  • 290 tickets were closed
  • 263 tickets were made live
  • 20 new Themes were made live
  • 243 Theme updates were made live
  • 10 more were approved but are waiting to be made live
  • 25 tickets were not-approved
  • 2 tickets were closed-newer-version-uploaded

There were two proposed themes for discussions and an open floor discussions

Proposal: Removal of the 1 theme limit rule

@thinkupthemes proposed that, following the discussion from the last meeting, we remove the 1 theme in the queue limit for authors to make the review more fair.
The 1 theme limit rule was added as a trial to combat review queue size.
Some argued that the rule was put in place to keep the queue fair and equally accessible to all (individual authors vs theme companies).

The leads and mods are working on a way to make final queue shorter and are trying to get active reviewers to help with the new queue, so that they can keep the queues shorter so that the one theme rule doesn’t have to be changed.

The problem is that the current admin queue needs to be shortened.

Another issue that was raised was the problem of onboarding of the new reviewers. The training instructions are often long and this can cause reviewers to drop out of the review process early on.

In the end the leads said they need to step back and reevaluate the new reviewer onboarding process and then look to reevaluate the admin queues purpose.

For the time being the removal of this rule was rejected, and the 1 theme rule stays in effect.

Empty CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. rules issue

There is an issue where authors just paste empty CSS rules in order to pass the Theme Check during the theme upload.

In some cases this covers things like image alignment classes, in other things like sticky posts.

It was proposed to require the align* classes and screen-reader-text classes, but the sticky class or bypostauthor classes shouldn’t be required (as they are not targeting functionality but rather design).

Open floor questions

Review onboarding

One of the open floor questions was the problem of training of the new reviewers. The reviewer onboarding process can be overwhelming. William Patton (one of the team leads) offered to do a pair mentoring on a theme with a new reviewer.

It was mentioned that two weeks of onboarding is too much – there is a lot of repetitive information, not enough videos, audios or lists which can be very easy to condense for someone who is learning. Maybe a step by step video of an easy to understand reviewer showing the process would help out.

Default theme

This meeting we had a special guest: @chanthaboune the Executive Director of WordPress project.

One of the main questions asked was the future involvement of the Theme Review team (TRT) in the work of the new Twenty Twenty theme. There was some issues raised like the fact that in the previous years nobody from the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team approached and asked the TRT for advice about the official requirements that themes in the 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 need to follow.

This resulted in official themes often violating the rules set by the TRT, which was then used as an excuse for theme authors to break the rules (appeal to authority set by the official WordPress theme).

Josepha acknowledged that her research on how the default themes have been worked on in the past are to be blamed of the lack of involvement of the TRT in the build process (a closed process).

So, the default theme, by my understanding is meant as a showcase of features, not necessarily a lighthouse for how all themes should behave this year.

Josepha Haden

@williampatton suggested that the new theme could be a place to see if the TRT could loosen some of the requirements

… loosening slightly with a watchful eye on the effects. Some guidelines may not be as useful as they used to be. And yes with intent to extend to all themes 🙂

William Patton

If the Twenty Twenty team wants to do something outside the guidelines the team would revisit that particular guideline and decide if it’s worth keeping.

Besides that, a question about the leadership was also brought up. Josepha mentioned that the team lead training content is written, but that the questions need to be sorted out.
William also mentioned that he’d be glad to help until a suitable replacement is found.

#meeting, #meeting-notes, #trt

Theme Review Team Meeting Agenda for July 09, 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. Because of numbers of agendas to discuss, we are going to discuss some agendas on second Tuesday as well.

We have several topic to discuss. Hence, we encourage all members and anyone interested to attend.

Channel: #themereview | Time: Tuesday, 09th July 2019, 17:00 UTC

Agenda for Discussion

  1. Weekly Updates
  2. Discussion with the #docs team about managing and taking over the theme handbook.
  3. Accessibility requirements – https://make.wordpress.org/accessibility/2019/06/30/accessibility-team-meeting-notes-for-28-june-2019/
  4. Removing Demo Content from the theme – We already agreed with this on removing from the theme. What are the alternative solutions that we can give to the authors instead of it?
  5. 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.
  6. 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

Meeting notes from the 25th of June 2019

The meeting started with a quick round of updates, mostly about the WCEU recap. 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).

Trusted Authors (TA) issues

First on the agenda was the discussion of the TA issues. There was a question of the quantifiable improvements from the TA program.
TA started on 30th of April last year, so having some data about it would be useful way to base decisions on.
Besides shorter queue, and more themes being set live (in the TA queue), the quality of code hasn’t really improved (that we know of). As mentioned by one of the leads

The improvements I have seen so far are faster throughput for SOME authors and slower for others. Code quality of non-TA has remained consistent. Code quality of TA has remained consistent too (but functionality and originality dropped).

There was a good point raised during the meeting, about pushing the authors to do more, but not better, since the program focuses on the quantity of themes, rather the quality. This can impact the originality and quality of the themes.

Underlying issue is that the review process in it self is too complicated, which affects the queue length.

Also there is no data to support either closing the TA or not. The discussion mostly went back and forth about what are pros and cons of the TA program without any conclusion

CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. upsell status

The repository with the customize section button was created and is currently being worked on – it’s working as is, there are some possible improvements in the build process that could be added.
This repository example doesn’t have to be used for upeslls exclusively. The 1.0.0 version should be out this week.
What we need is a code review to make sure everything is ok to be used in themes.

Another project that was started was the PHP autoloader for the people not using Composer to be able to use the customize section button in their themes.

Some members were worried how to use the above code without the use of Composer, but it was explained that the code can be copy/pasted – authors can download the ZIP, use GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. clone, Git sub-module, or Composer dependency in their themes.

Removing child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. queue

The advantage of the child theme queue is that those themes get set live pretty fast, and this makes authors submit more child themes.

A lot of people were for removing the child theme queue, as the requirements regarding them are not clear enough, and it makes the regular queue longer.

The conclusion to close it wasn’t reached, and the leads mentioned that they will reach a conclusion based on the provided discussion.

Final remarks

In the end, one of the theme review leads recommended that we try halting the TA queue until the final queue gets cleaned, because if only TA themes get set live, this puts the non TA authors in a bad position.

We will try the idea that if final queue has more than 50 themes then TA approvals are halted.

#meeting, #meeting-notes, #trt