Bug Scrub Schedule for 5.4

Now that 5.4 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. Keep an eye on this schedule – it will change often to reflect the latest information.

  1. 1/21/2020 19:00 UTC
  2. 1/29/2020 23:00 UTC
  3. 2/7/2020 05:00 UTC (APAC-Friendly)
  4. 2/10/2020 16:00 UTC
  5. 2/18/2020 20:00 UTC
  6. 2/27/2020 23:00 UTC
  7. 3/2/2020 16:00 UTC
  8. 3/11/2020 TBD (If Necessary)
  9. 3/17/2020 TBD (If Necessary)
  10. 3/27/2020 TBD (If Necessary)
  11. 3/30/2020 TBD (If Necessary)

These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:

Design Triage: Every Monday 17:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, the ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC will continue during the cycle, alternating focus between core and editor.

Next, the Accessibility team has announced a few extra scrubs for the 5.4 cycle. You can read about those here.

Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.4-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

All open tickets for 5.4, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.

#5-4, #bug-scrub

Editor Chat Agenda: 26th February, 2020

Note taker: @ajitbohra

This is the agenda for the weekly editor chat scheduled for 2020-02-26 14:00 UTC. This meeting is held in the #core-editor WordPress Slack channel.

  • WordPress 5.4 Upcoming Release
  • Gutenberg version 7.6.0
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post. If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.


Lazy-Loading Update

Since lazy-loading images via the native loading attribute was proposed for addition to WordPress core, there have been quite a few updates. With the WordPress 5.4 release cycle entering beta almost two weeks ago, there was too little time for testing the feature plugin and creating a proper core patch. The feature is now aimed at being released as part of WordPress 5.5, to be merged early in the release cycle to get further testing while fully integrated with the platform. This post is a follow-up to the original announcement, providing information about the latest updates.

Standardization of the loading attribute

The WHATWG spec pull-request for adding the loading attribute to img elements with possible values “eager” and “lazy” was recently merged, so it is now part of the HTML Living Standard (see general paragraph about lazy loading attributes and more specific information about the img loading attribute). This was a requirement for WordPress to ship with support for the feature. While it was unclear whether this was going to happen in time for the WordPress 5.4 release (which it now has), the 5.5 timeline certainly works for it, as now the feature can be merged way ahead of the initial beta.

Browser support

At the time of this publication, Chrome (76+), Edge (79+) and Opera (64+) already support the loading attribute. Firefox support was merged recently, and is intended to land in version 75. WebKit support is actively being worked on, so seeing the feature land in Safari is also on the horizon. We will monitor how browser vendors are adopting the standard, but with recent developments it looks promising. All major browsers will support the loading attribute by the time WordPress 5.5 is released (currently 2020/08/11). Please refer to caniuse.com for current updates.

State of the feature plugin

The feature plugin for lazy-loading images in WordPress core (GitHub repository) is in a good state to be used already. The exact implementation is undergoing some changes, mainly focused on optimizing the mechanism to add the loading attribute to images in post content for performance by combining it with the existing regular expression in core that adds srcset and sizes attributes. These changes will likely affect the new APIs outlined in the original post, and a dev note about the definite state will be published closer to the WordPress 5.5 release.

The plugin is ready to be widely tested. It has already undergone some testing, but we are looking for more testers! We will also like to receive any type of feedback on the implementation.

XML Sitemaps Meeting: February 25th, 2020

Last week we held the first of many weekly meetings for the XML Sitemaps feature project on Slack.

Meeting Recap: February 18th

We had quite a few people attending, not all of whom were familiar with the project. Thus, we started off with a small recap of the project’s scope and goals. After that we discussed various different topics:

  • How to modify the sitemaps to include/exclude certain URLS
    A pull request has been opened to add a FAQ section to the readme that aims to answer these kind of questions.
    Also, a new way to filter WP_Query instances used for sitemaps has been proposed.
  • Why are there no changefreq and priority fields?
    Those are optional fields in the sitemaps protocol and not typically consumed by search engines. The feature plugin follows other solutions like Yoast SEO who also don’t include those fields.
    Developers can still add those fields if they really want too.
  • Will there be UI controls to include/exclude content from sitemaps?
    Adding UI controls is currently a non-goal for the project.
  • Calculating the last modified date for URLs
    This is rather difficult and computationally expensive in WordPress. Given that sitemaps are first and foremost a discovery mechanism for content, having this data is not necessarily required. We will explore omitting this functionality (GitHub issue).
  • The default limit of 2000 URLs per sitemap is considered high and might need to be re-evaluated.
  • Potential compatibility issues with other XML Sitemaps plugins have been discussed.
    If a site ends up having two sitemaps by accident that wouldn’t be bad. However, the current /sitemap.xml URL might clash with other plugins. A GitHub issue has been opened to suggesting using /wp-sitemap.xml as the base. This would avoid conflicts in this regard.

Agenda: February 25th

The next meeting will be held on Tuesday, February 25 at 16.00 CET

For tomorrow’s meeting, the agenda is rather brief:

  • Updates since last week (merged changes, new issues)
  • Next steps for proposed lastmod changes
  • Next steps for URL naming change
  • Planning release of version 0.2.0

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #seo, #xml-sitemaps

WP Notify weekly meeting agenda for Monday 24 February 2020

This is the agenda for the next WP Notify feature project meeting, to be held today, Monday, February 24, 2020, 14:00 UTC.


  • Opening and welcome
  • Reviewing and updating the requirements document: Current Status
  • Reviewing and updating the requirements document: Project Goal
  • Open floor

If you have anything else to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications

Dev Chat Summary – February 19th, 2020 (5.4 week 6)

@francina facilitated the chat on this agenda

@cenay took care of publishing the summary notes. Special thanks to @valentinbora, @amykamala and @audrasjb for the peer review on these summary notes. 

Full Meeting transcript on Slack

This devchat marked week 6 of the 5.4 release cycle.


WordPress 5.4 Beta 2 was released yesterday, February 18, as scheduled.

  • 5.4 Beta 3 is scheduled to be released on February 25, 2020. (Note to committers and maintainers, the cut off time to get bugs fixed and into WP 5.4 is February 25th, 20 UTC)
  • 5.4 is intended to be released March 31st, 2020.


  • Status report on the About page – content and design
  • Dev Notes status and how to proceed to get them all published in time for RC1 and the Field Guide. 
  • Highlighted Posts: XML Sitemaps Kickoff Meeting Announcement 
  • Component Check-ins

5.4 Beta 3 to be released on February 25th

As mentioned, WordPress 5.4 Beta 2 was released on February 18th, 2020. 

Please help by testing the Beta and reporting any bugs on WordPress Trac (or the Gutenberg GitHub repository).

@audrasjb suggested it would be great to schedule one or two bug scrubs before the next beta so we can punt/help the 134 remaining tickets in the milestone. @francina “seconded” with a call out for anyone who has spare time to help organize a bug scrub (See this post for how to run one). Open tickets for 5.4 can be found here (in order of priority). The Bug Scrub schedule for 5.4 lists scheduled scrubs for anyone to join in. 

Status Report on the About Page – Content and Design

@karmatosed stated everything is lining up to start the About page earlier this release. There will also be a push to document this. @melchoyce and @elmastudio are leading the design charge on this with @marktimemedia riding along to observe. @marybaum added they’ve got chunks of the copy written and she promised to share it with major-release-squad.  

Dev Notes Status 

..and how to proceed to get them all published in time for RC1 and the Field Guide.

@audrasjb reports since the last dev chat, four new dev notes were published:

@audrasjb also reports to date, they have a dev note published for about 50% of closed tickets with the `needs-dev-note` keyword in the milestone and 4 drafted dev notes ready to publish. He is very confident they’ll have all dev notes published by the end of the month (during last week before RC1)

@jorgefilipecosta reports he is tracking the progress of the block editor related dev notes and requests that any feedback before the dev notes are published would be great as the content there was not yet reviewed and is just what the original people involved in a PR think the dev note should contain.

@johnbillion asks that if anyone sees changes going into core that they think need a dev note, to leave a comment on the ticket. @audrasjb adds “if you think there are some important tickets that don’t have the `needs-dev-note` keyword, please get in touch with me”. @azaozz asks that you ensure the dev notes are really for developers and are concise and to the point and preferably with a code example of changed usage. @jorbin reminds us to remember the guidelines for posts and the need to have a peer review. 

@francina thinks having a separate page with guidelines on submitting dev notes would be helpful. @earnjam mentioned @desrosj would have a draft written up on the subject.

Highlighted Posts

@francina announced the highlighted post. There were no comments. 

Component Check-ins

  • News from Components
  • Components up for adoption (i.e. looking for maintainers): Filesystem API and Rewrite Rules
  • Components that need help
  • Cross component collaboration

News From Components


@valentinbora reports 1 week after he took up Administration, 40+ tickets have been triaged with 2-3 moved to other components. Per the previous meeting’s discussion regarding the very existence of the Administration component, @valentinbora thinks it’s here to stay.


@jeffpaul raised the issue of Gutenberg development overlapping existing Core components and how to best communicate with their respective maintainers/teams. @francina proposed a continued discussion about the cooperation between Components and Gutenberg out of the meeting.  

Widgets & Menus

@audrasjb noted 3 bug fixes with `commit` keyword and concerns about managing the transition and backward compatibility with tickets referring to current widgets/menus and new tickets referring to full site editing (FSE). 

@noisysocks recommends that maintainers of the widgets, customizer and editor components get involved and look at the relevant labels in the Gutenberg repository. 

Open Floor – Announcement

@pbiron announced that a new version of the WordPress Beta Tester plugin was released earlier today with a new feature. On the settings screen (`Tools > Beta Testing`), once you’ve already updated to either `Point release nightlies` or `Bleeding edge nightlies`, you’ll see a new option for `Beta/RC`. Once you’ve set that as your current stream, you’ll only be updated when the next beta or RC (or official) is released rather than the nightlies. 

One advantage of this new feature is that you’ll be able to update to beta or RC packages right in the Dashboard (Dashboard > Update) as soon as the packages are built during the release parties if you’re not comfortable using wp-cli.  Hopefully, this will increase the pool of testers during the release parties.

As the meeting was over time, the remaining two topics from today’s agenda were not started. 

Action Items

These items were discovered within the content as stated action items.

  • @francina to add the bug scrubs to the meetings page (like she did for 5.3)
  • @francina to add “creating a separate page with dev note guidelines, adding comments to a ticket” to her desiderata. Check with @desrosj who might have a draft of a page with details about how to write a good dev note.
  • @audrasjb and @welcher should look at Widgets/Menus issues/PR on Gutenberg
  • @noisysocks to add a ‘call for volunteers’ to the next core editor chat to implement proactive communications from Gutenberg to those component maintainers to help find ways to work together.
  • @jeffpaul suggests we call out notice to the new WordPress Beta Tester plugin in the Beta 3 blog post (and future posts as well) so folks looking to help test have a starting place. 
  • @clorith wants to chat about how to move more things into a React world and how to do it outside of Gutenberg.
  • @noisysocks to “put something up” on Make/Core to continue the conversation about cooperation between Components and Gutenberg (i.e. Cross Teams Collaboration).

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, Wednesday, February 26, 2020 at 21:00 UTC

#5-4, #summary

Working on Trac Tickets Using GitHub Pull Requests

WordPress development uses SVN, but many contributors prefer to work in Git through GitHub. For some contributors, that means working with a cumbersome workflow within Trac. Many contributors create pull requests using their own forks of the official WordPress Develop mirror so that they can use features like continuous integration and inline code commenting. Historically, though, it has been hard to cross-reference between the two systems.

Starting today, an experimental feature has been added to Trac that will let you link GitHub pull requests opened against the official WordPress Develop Git mirror to tickets. This makes GitHub contributions more visible directly in their related Trac tickets and makes collaborating across the two repositories easier. (Better contributor experiences, ftw!)

Note: this is not a signal of any decision to start moving WordPress to Git, GitHub, or GitLab. That is something that is still being explored separately and independent of this feature. There is no further update on that at this time.

How It Works

In GitHub

In Trac

  • The PR will be displayed below the attachments area on tickets with the following information:
    • How many lines were modified
    • Status of the PR checks (Draft/Closed, Travis CI, merge conflicts, etc.)
    • A button to view the PR
    • A button to view the raw diff
  • A bot comment will be added to the ticket’s timeline of events indicating when the ticket was mentioned and where.
  • Every time the PR receives a comment, a PR bot will post the comment onto the Trac ticket.
A screenshot of a WordPress Core Trac ticket with the new linked Pull Requests between the ticket attachments and comments.
Pull requests show between Attachments and Change History.

Important Notes

Trac remains the source of truth for all discussion. If you prefer to continue working in Trac, that’s OK! Nothing will change on Trac itself other than what is noted above. Nothing about how you contribute has to change!

When the PR bot syncs comments over to Trac, it will not trigger an email notification to the subscribers of the Trac ticket. For this reason, it is recommended to provide some type of ticket update in Trac itself. Most likely there will be a need to update the keywords anyway (add has-patch or needs-testing, etc.).

Comments made during a code review on the PR will not be posted to the Trac ticket. These comments are usually specific to the code being reviewed, so this should be OK. If this causes confusion, syncing these can be explored.

No changes to WordPress Core will be merged through GitHub pull requests. This is not new and remains the same. This feature is meant to make contributions done through PRs on GitHub more transparent in Trac.

Pull requests on GitHub are not monitored. No one will be checking for new pull requests regularly. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core.

Clean up after yourself occasionally. Right now, PRs are not automatically closed when the associated Trac ticket is resolved. If you open a PR, do your best to close PRs that have been merged into Core whenever you are able to.

And finally, this is an experiment. There will likely be some small bugs and things that can be improved since this is the first iteration. Please open up tickets in Meta Trac for any issues that you find. All feedback is welcome! Please leave your thoughts in the comments of this post below.

Props go out to @noisysocks, @pento, @desrosj, @andraganescu, @isabel_brison, and @talldanwp for working on the initial iteration of this feature, @dd32 for heavily overhauling for and deploying to production, and @chanthaboune for helping to proof read this post.

CSS Chat Summary: 20th February 2020

Full meeting transcript on Slack.

I (@isabel_brison) facilitated the meeting. 

The agenda was empty except for Open Floor.

I proposed a question to reflect on for this and future meetings: “What, if anything, should we improve about our CSS in core and/or gutenberg? And what, if anything, are we already doing particularly well? “ (If anyone reading this would like to contribute an answer, feel free to pop into the next meeting, or just add a note to the agenda if you can’t make it to the actual meeting!)

@bemdesign expressed concern that the adoption of modern development approaches, especially CSS-in-JS, and the build tooling necessary for React apps, might over-complicate the process for new developers to get started.

We discussed how to ease the learning curve and make it easier for new developers to get involved: 

  • Choosing tools with an easier syntax (in the CSS-in-JS case)
  • Education and documentation
  • Out-of-the-box build configs, such as @wordpress/scripts

Then, going back to the initial question, @peterwilsoncc suggested overly high specificity of some CSS selectors could be improved, and ideally we should have a consistent level of specificity throughout.

@youknowriad added that we should try to create style variations in components instead of trying to override default component styles with additional classnames.

@laras126 suggested using single-declaration utility classes that sit further down the cascade, and passing in classnames as props.

We agreed backward compatibility may make it hard to change our current approach completely.

Open Floor

@laras126 shared a link to a CSS working group discussion on the benefits of introducing a new CSS version.

We briefly discussed how a new version (CSS4) might be useful to us: adding visibility to current best practice approaches and as an encouragement to developers to learn the spec better.

That was all!

#core-css, #summary

Components Maintainers and Gutenberg

In this week’s DevChat, @jeffpaul asked:

One thing I’ve become curious about is how some components should potentially be looking to support current/future phases of Gutenberg? Thinking here about Customizer, Widgets, Menus, and the like. Is there anyone on the Gutenberg team that’s working with those components to see how those maintainers/contributor teams could help advance Gutenberg development from their unique perspective from a core component team?

Some discussion ensued, but it’s an important topic that’s worth discussing in an asynchronous forum where people from all timezones can participate.

So: How do we ensure that there is good collaboration between Component Maintainers and the Gutenberg project?

WP Notify Meeting Recap – February 03 2020

This is a recap of the WP Notify meeting held on Monday, February 17, 2020, 14:00 UTC. You can read the meeting discussion here.

We opened by reviewing the Use Cases section. We moved an item related to which users plugin or theme notifications should be shown to, down to a later section in the document (Wish List Items), to be discussed at the relevant time.

@folletto noted that “here we are a bit playing a double role, use cases for users and use cases for developers. These luckily overlap a bit, and I think what we have is a good compromise”. @psykro left a comment that we might need to expand on use cases. We also had a brief discussion about the section on state changes. While the ultimate goal would be for WP Notify to replace those as well, this might not happen in our first release.

We reviewed the current status of the new Current Status section and had a discussion on the terminology related to the different types of notifications. @folletto suggested the following:

  • Notification = a notification hub, with maybe a dropdown or a container of some sort, that shows alerts across pages
  • On Page = a local notification, shown only on a specific page, and contextual to the page content

Finally we removed the admin_notices graphic from the Current Status section.

As always, we invite the community to share their feedback on any of these changes to the document, either here in the comments or on the document itself.

Next Slack Meeting

📅 Monday, February 24 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary

Editor chat summary: 19 February 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, February 19, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. The meeting was moderated by @gziolo.

WP 5.4 Beta 2 Released

The release contained several fixes for the editor. A few notable items:

  • Block editor: Columns in the Block Library that have unassigned-width will now grow equally.
  • Block editor: The custom gradient picker now works in languages other than English.
  • Block editor: When choosing colors is not possible, the color formatter no longer shows.

Everything can be viewed here. We still have some ongoing work in the must have board. Props to all involved in the process, with the big shootout to @jorgefilipecosta for wrangling all the boring work of syncing all those fixes in WordPress core. Friendly reminder for those who are aware and explanation to everyone else about the workflow during WordPress release cycle. Next release will be the last beta version. That means the first RC and the string freeze is very close. Until WordPress 5.4 is out, we do the regular release for the plugin every 2 weeks. At the same time, we only backport essential bug fixes to WordPress core. It means that we don’t do regular publishes to npm for WordPress packages.

The dev notes work is going well and post notes are already written. Thank you to all the helped this effort and wrote dev notes

Weekly Priorities

The February plan is still in motion: 

  • Expect Gutenberg G2 to land in the next weeks
  • Global styles being a focus
  • FSE ongoing project that will continue for a few weeks/months

Get involved in FSE work (blocks being added, themes being explored). There’s room for a lot of work there and not enough people at the moment. There is work being shared around the UX flows for template-parts, and navigation. Providing feedback there can help move things.

Task Coordination

@karmatosed deep down in global styles-land we have new mocks. I’ve also been giving feedback where can on some tickets, keeping that triage flowing.


  • Still working on my ongoing wordpress/icons project
  • Added a bot that shows the impact of PRs on bundle size (I hope it’s not annoying you and that we’ll actually pay attention to the changes)
  • Working on the last G2 details before initial merge (hopefully this week or beginning of the next one)
  • A lot of reviews (SlotFill, FSE blocks…)
  • Some block-based themes explorations.

Nothing blocking so far


  • Continue with Global Styles. Hands on with FSE integration alongside @nosolosw. Otherwise, planning/coordinating
  • Helping folks like @youknowriad on G2 (Movers interaction specifically)


  • Iterated on a proposal for the resolver that enables authors to target specifics parts the post (“all block paragraphs”, “cite within blockquotes”, etc): PR 20290
  • Bootstrapped a barebones global styles theme for demo purposes PR 22
  • Prepared a PR to explore a different isolation mechanism and how the process of migrating blocks to use CSS variables may look like PR 20273 
  • For next week, I’m going to carry on that work and potentially resume the PR to connect the server data to the UI Controls PR by @itsjonq.


  • Merged a PR to enable the creation of Pages from within the Navigation Block.
  • Seeking reviews on another PR to improve the documentation around the `<LinkControl>` component:


  • Working through Block Patterns with . He’s going to explore a simpler MVP approach to get patterns in quicker.
  • Exploring UX around template parts.


  • Getting caught up to start contributing again after being away for a few months while moving into a new house. You all move so fast! The last thing I had been working on was going through all the components to add them to Storybook.
  • Doesn’t look like there has been a ton of movement there, thoughts if that would still be worth my time, or should I look for somewhere else to start contributing (FSE?)


  • Working on documentation, dev notes, e2e tests for block variations API.
  • Introduced stable BlockSettingsMenuControls slot
  • Planning to help land changes for SlotFill refactor, want to finish Puppeteer upgrade, also want to work on optimizations for block editor build process in core.

Open Floor

Conflicts in Blocks with Vertical Aligned Columns

@leemon asks for a look at this Issue 19962, please. This bug affects many block plugins. I think it should be fixed in 5.4 @jorgefilipecosta This issue was already part of the must have board, unfortunately we did not fix it before the beta. If the fix is something very simple that we could include as a bug fix it would be good, but it is not something critical given that 5.3 already contains this bug.

Conflicts in Blocks with Vertical Aligned Columns

@isabel_brison General comment and feature proposal: gutenberg.run has been extremely useful for cross-platform testing, especially in an accessibility context. It would be great to have something similar for Storybook too! A few months ago, before gutenberg.run was working, I investigated using Tugboat for generating PR previews. It might be a good tool for a storybook preview, as it’s fairly simple to set up.

@gziolo There are two parts there, it feels like it’s time to document and promote gutenberg.run. It works great! @youknowriad For the second part, we discussed building Storybook into WPAdmin somehow and just use a single tool (gutenberg.run) for all. @gziolo  We had integration for Storybook but there were some issues with using commercial hosting. I remember that discussion. It sounds great. Let’s open an issue for that if it doesn’t exist.

Nested Blocks in FSE

@BMO  Does anyone have any updates on nested blocks and the impact on FSE? For example, being able to use semantic HTML in a template file? @jorgefilipecosta I think the solution is to provide head blocks and things like that @gziolo opened a PR 20218 that explores ways to make Group block flexible enough to cover this use case. @jorgefilipecosta making the group support several different tags may be a good solution.

@kjellr  The current block-based themes spec doesn’t include anything about structural tags like <head>. That’s probably something we should consider separately.

@gziolo It raised the question how flexible it should be, should we allow any tag?, etc. I’m sure other questions will follow, like how to mark those groups as landmarks, whether to include visually hidden heading and similar accessibility related optimizations to start we should define the list of core supported semantic tags used for grouping and how they would look in the inserter. I would also like to discuss it with the accessibility team on how we can ensure the best possible experience

@BMO  To ask what is probably an obvious question, is the focus or intent to prevent arbitrary HTML inside of template files? Because everything could/should be handled with a block? @youknowriad the answer is yes, because it needs to be editable as a block, though we have custom HTML block, custom classNames, etc. @BMO The group block solution looks interesting because it keeps these things nested.

Block-Based Theme Bi-Weekly Meeting 

@kjellr  Since we’re on the topic: every other week there’s a block-based themes meeting where we’re discussing these things too. The meeting is held in the themereview slack channel. For more information visit https://make.wordpress.org/themes/