Make WordPress Core

Keyboard Shortcuts | Hide comment threads

5.3 Retrospective – Call for feedback

5.3 “Kirk” was released on November 12, 2019. It was twelve weeks in the making, it had a big team behind it and the highest number of contributors ever. Congratulations to everyone!

In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:

  • What should WordPress start doing as a part of the development process?
  • What should WordPress stop doing as a part of the development process?
  • What should WordPress continue doing as a part of the development process?

Please share your thoughts in the comments below! Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

#5-3, #retrospective

Consent has been the #1 topic for me this year and my concerns keep growing. I am a huge fan of asking for opt-in and not forcing users to opt-out of something they never agreed to or expected based on previous expectations such as the WordPress philosophy and the four freedoms.

Example in case, the media upload auto downsizing feature already bit me w/ a few LMS sites that updated and needed certificates updated last minute (300dpi images used w/ GD Library output to pdf) where students were not receiving properly formatted certificates upon completion of courses and were severely distorted because no one knew that WP.org had decided to push a new feature that has all the intentions of not allowing end users to upload huge images impacting the performance and user experience of their sites…all the while affecting these already in production web site’s actual user experiences in a totally destructive way.

Yes, we learned we can disable this new “non-web-savvy protection feature” with a filter but this is not aimed at your average users expertise level.

So you created a new feature to help the non-web-savvy folks from hurting themselves but if they want to opt out, they better be web-savvy, all the while hurting existing users that need this to work the original way it has for years or at least an easy way to turn on/off. This logic is lost on me.

That said, I prefer providing feedback face to face because text leaves so much to assumption, I hope this comes across as constructive criticism of recent changes and discussion where new features affect existing already working features without any up front consent or at least a notice prior to upgrade that spells out exactly what to expect from the changes, how to enable them if desired, not the other way around. I want to tick a box after I upgrade to enable new stuff vs having it forced enabled and the only way to override is digging through the developer docs.

Personally I prefer a modular upgrade system where post upgrade, everything considered as a new or enhanced “feature” and not a bug or security patch should be an option that we enable only when/if it’s desired. I believe this would lead to less post-upgrade issues and also lead to site owners knowing their sites more intimately being forced to get involved with their admin settings to enable and use new features.

Oh and thanks for asking for this feedback, I am glad you are open to hearing our concerns along with our praises. I should also add, the new Twenty Twenty theme is a masterpiece, great job and thank you!

The “handling of BIG images” is a horrifying implementation that goes against everything the internet is about and all current consent and privacy laws. I’ve spent four hours trying to figure out what was wrong with my newly uploaded images. I have three high-res sites with the widest images being 3600px. One landing page has a fullscreen image that is 3600 x 2025px at 135kb. I know how to optimize my images and I do them individually by hand. I don’t need to be locked down.

This size limitation is implemented without my consent and without me even knowing about it. I highly doubt it’s legal. And to make matters worse you offer no way to easily disable it.

We are moving toward higher and higher resolution, not the other way around. Do you realize that you are destroying websites and ruining people’s businesses with this? Image handling in WordPress has always been mediocre but with this new addition it becomes a disaster. There are already plugins that handle images superbly. Why don’t you spend your time and effort on enhancing support for high-res images and support what is already in place by third-party developers instead of going against the flow and evolution? High-res is here to stay, don’t go back to 1998.

I think you should pull this update before the damage worldwide is getting out of control and issue an apology to all your users.

Yes, I’m angry and I have the right to be!

There should be option in the Settings > Media to enable/disable the image resizing feature and by default it should be disabled. It’s really annoying that i had to disable it on few sites already through the filter so far and likely many more are coming.

Is there a way to disable this new high contrast theme and revert back to the original one? I do support accessibility admin theme with higher contrast etc but:

  • why it’s turned on by default?
  • why it can’t be turned off?

I’m fine with less contrast, I don’t like this new one. Do I have any choice?

Start

Stop

  • Ignoring new patches by contributors for years. Right now is easy to get demotivated on contributing with core to WordPress because is difficult to get feedback on code patches, and without code patches the project will not move on and grow.
  • Stop to release a project by time period instead of feature ready. If I have a company that has a business around a project I cannot upgrade to something that has issues. For 5.3 we got 5 RC that are a clear symptom of something that wasn’t tested enough or feature ready.

I hope that WordPress get more attention in getting more bug fixed instead of new features that maybe will implement more bugs. There are tons of tickets very old but still real like http://wayback.fauppsala.se:80/wayback/20191117163844/https://core.trac.wordpress.org/ticket/21402 that talks about remove php 4 code compatibility.
Please give more love to what there is on Trac instead of new stuff.

Dev Chat Summary: November 13, 2019

@francina led this week’s dev chat – the last one of the 5.3 release cycle – see the agenda here.

For the full transcript, see the Slack archive here.

Your faithful reporter: @amykamala. Let’s get going!

Announcements

@francina opened Announcements with the release of WordPress 5.3, which went live on November 12, 2019!

She congratulated everyone, NOT just the folks active in the chat, on an amazing job. Several Core committers were especially pleased that 5.3 came in on schedule (🎉) with the biggest group of contributors ever.

Here are a few statistics:

  • 12 weeks of development
  • A release squad with nine focus leads, covering every relevant component that got an update
  • 645 contributors
  • 658 bugfixes
  • A new default theme, Twenty Twenty
  • Lots of fun and new friends made
  • And much, much more!

Before release the squad counted at least 153 user-experience enhancements.

Highlighted Posts

The annual WordPress survey is open! Your feedback is not just appreciated – it’s vital to the future of WordPress. So please fill it out and share it everywhere you can think of.

Tanking the floor for a moment, @chanthaboune told the group this survey is new – not the same as last year – and is broader. Whether you’re a contributor, designers, developers, users or hosts, please participate!

Again, please share the survey with anyone who touches WordPress in any way.

5.3 Housekeeping

Big thanks to everyone who has helped with testing so far! If that includes you, please keep testing and report any issues, concerns or enhancement ideas in a comment on Trac.

That’s how WordPress gets better and you get to shepherd your best ideas through the process.

Need a refresher on how it works? Here’s an outline of the post-release process.

@francina wrapped the discussion with a note that in the next few weeks the release leads will open a call for retrospective. Want to share some honest, constructive feedback? That’ll be your chance!

5.3 Housekeeping Calls from component maintainers

@francina opened the floor for component maintainers to bring up topics for discussion. These are the components.

@marybaum said “I love that we have a #core-css channel. Does that mean Core CSS is a component?”

@peterwilsoncc replied, “it’s closer to a focus than a component. Tickets can still be assigned to the affected component, eg Admin, Themes, etc. “

@sergey asked “If we have a `javascript` focus, should we add one for CSS as well? 

After a few more comments from folks, @francina reminded all 30,000-plus potential attendees that we don’t make final decisions in devchat.

She asked the folks talking about CSS to follow this process:

  • Make a proposal on the Core blog
  • Discuss
  • Come to a conclusion
  • Act

Here are the reports from other component maintainers:

@williampatton: “Themes component is looking good. Prepping for next release.” 

@peterwilsoncc: “From the security team, now we have a Travis CI account that allows for private repos, we have the security tests running regularly. It should make it easier to find out if they’re passing during the release process.” and went on to ask @sergey if it was possible to add it to Trac.

@garret-eclipse: “In the privacy component @rogierlankhorst has started work on a consent api.

Open Floor

@mensmaximus asked whether “we ever change the user management screen to a tabbed interface. What is the current state and what do core devs think?”

@williampatton started with a general reply: “There are lots of thoughts on redesign for user management, but lots of ideas mean lots of decisions [making it] hard to reach agreement.”

A lively discussion followed. Hopefully the WordPress world will see some new ideas for an even more usable Admin experience!

(Ed. note: The UX discussion and the conversation below, about jQuery, happened at the same time, and you’ll see the comments jump from one to the other. Still, imo, both are worth your time and effort to decipher!)

@enrico.sorcinelli has “noticed that Juery’s `$` is no longer globally defined in admin.” That’s made some of their client sites cause issues with users’ code.

@clorith answered, “The jQuery `$` being globally available was a bug.” That bug got fixed in one of the JS updates in 5.3.

“Although it’s not ideal, reports of issues are fewer than expected, and the code errors would be within the plugin code,” @clorith continued, adding, “I tend to lean towards leaving it being the right thing.” 

Here’s the ticket they’re talking about and the full discussion, including some observations on the future of jQuery.

@clorith noticed two items leading the pack of recurring issues, 24 hours in:

  • The update to add_submenu_page gives doing-it-wrong errors. We knew this, but devs weren’t prepared for users to have debugging enabled. 
  • The change to spread operators had plugins breaking, because things like custom walkers had dependencies on the previous operators.

See the full discussion starting at the link above. (Ed. note: this highlighted test is the same link.)

@pbiron asked if anyone had reported problems with the new big-images or rotate-on-upload features. 

@clorith and others noted very few issues.


#5-3, #devchat, #meeting-notes

REST API Chat Summary: November 7

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcript, Agenda). Please note that this meeting did not change time for daylight savings, and Weekly REST API component office hours continue to be held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack. 🙂

Authentication

The first half of the meeting discussed the newly-created wp-api/authentication GitHub repository, a follow-up to discussions at WCUS contributor day around rebooting work towards a canonical, core Authentication solution to permit the Mobile team to use the REST API instead of XMLRPC.

Our target for a merge proposal some time next year is to have an use the OAuth 2 handshake flow with dynamic client registration, which issues revocable, long-lived JWT tokens. The repo has no content so far, but we will start work by focusing on UX and the desired user-facing and technical flow rather than diving immediately into code.

@spacedmonkey, @derekherman, and others intend to drive this project over the coming months. If you who is reading this or any colleagues of yours are interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday, November 14, 2019 at 06:00 PM UTC) as a weekly standup to coordinate work.

Priorities & Goals

Priorities for Next Release

Key tickets highlighted for consideration as part of the next release cycle include, but are not limited to,

  • Improve performance in route matching #48530
  • Support registered default meta values #43941
  • Permit schema filtering #47779

If you have a ticket to highlight or propose for the next bugfix or major release, please leave it as a comment below or raise it in #core-restapi. Thank you once more, as well, to everybody who helped drive our API improvements in 5.3!

Documentation

We are behind schedule in updating the REST API handbook to cover the recent changes in WordPress 5.3. @timothyblynjacobs and @kadamwhite will be working to roll these updates out over the coming week. Handbook content is managed at github.com/wp-api/docs.

Open Floor

@timothyblynjacobs raised #44568 and #44886. Because WordPress operations are non-atomic, these race condition issues are not limited to the REST API and were determined to be out-of-scope, so #44886 was closed as wontfix.

Several bugs were raised and have been provisionally milestoned for 5.4, with the option to backport as needed once addressed.

To increase contributor awareness of REST API tickets, we discussed holding periodic component scrub meetings in the main #core channel.

Agenda for November 14

The next REST API meeting is happening shortly in #core-restapi at Thursday, November 14, 2019 at 06:00 PM UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api

What’s new in Gutenberg? (13 November)

In this newest release of Gutenberg, block content areas and the navigation block continue to be iterated upon. An experimental block pattern API has been added, and themes can now define custom gradient presets!

The navigation block, demonstrating newly improved horizontal block movers.
The navigation block, demonstrating newly improved horizontal block movers.

The block editor provides default gradient presets. Now, a theme can overwrite them and provide its own:

1
2
3
4
5
6
7
8
9
10
add_theme_support(
    '__experimental-editor-gradient-presets',
    array(
        array(
            'name'     => __( 'Vivid cyan blue to vivid purple', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)',
            'slug'     => 'vivid-cyan-blue-to-vivid-purple'
        ),
    )
);

Note that this feature is currently experimental and subject to change.

6.9 🇦🇷

Features

Bugs

Enhancements

New APIs

Various

Experimental

Documentation

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 6.9.0 11s 77.36ms
Gutenberg 6.8.0 11s 74.78ms
WordPress 5.3 10.6s 80.85ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Dev Chat Agenda for November 13, 2019 (Post 5.3 week 1)

Here is the agenda for the weekly meeting happening later today: Wednesday, November 13, 2019, 09:00 PM UTC.

Agenda

  • Announcements
    • Highlighted posts
  • 5.3
    • Housekeeping
  • Calls from component maintainers
  • Open Floor

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

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

#5-3#agenda#devchat

Core editor chat summary November 13th, 2019

This post summarises the weekly editor chat meeting, agenda here, held on Wednesday, November 13, 2019 at 01:00 PM UTC in Slack, moderated by @jorgefilipecosta, notetaker: @andraganescu

Next week’s Core editor chat time: 14 UTC

Because of DST there was a decision to move the meeting one hour later. The async discussion is still open until Monday, November 18, 2019 at 12:00 AM UTC to decide if people, other than those present at he core editor chat want it differently.

WordPress 5.3 was released yesterday

@youknowriad: Big kudos to all the contributors. It’s a huge release for the block editor

@jorgefilipecosta I would like to thank all the people that contributed and made all this improvements and bug fixes possible!!

There is some current effort to iron out issues that may appear.

Gutenberg 6.9 will be released today

A Release Candidate is already available at http://wayback.fauppsala.se:80/wayback/20191117163844/https://github.com/WordPress/gutenberg/releases/tag/v6.9.0-rc.1

@aduth and @ella are working on that (release post and performing the release)

Weekly priorities

The main priorities are the same ones highlighted in the November post What’s next in Gutenberg? (November) – Make WordPress Core

Also, one of the priorities is to fix WordPress 5.3 regressions as they come up.

Task coordination

@youknowriad

  • I was AFK for some days post WCUS
  • I worked on the WordPress 5.3 release a little bit
  • I’ll be focusing on support, triage and reviews for the next week.

@karmatosed

  • Navigation block: styling, reviews and testing
  • Triage: I want to dig in a bit and try and clear down low hanging tasks
  • Begin working out sprints for Tightening Up board. I have an idea to for 1-2 weeks focus on an area, move on and repeat.
  • Support is for me next week so last point won’t happen until week after.

@retrofox

@getdave

@pbrocks

@michaelarestad

  • starting in on full site editing – largely research/information gathering at this point

@mapk

  • Helped review some of the Nav block work.
  • Worked on the Media replace flow.
  • Reviewed linking media in Media+Text block.
  • Helped @michaelarestad with some full site editing research.

@andraganescu

  • continued on the navigation block
  • need a code review on the media replace control here: http://wayback.fauppsala.se:80/wayback/20191117163844/https://github.com/WordPress/gutenberg/pull/16200

@nerrad

@jorgefilipecosta

  • I finished a big refactor for the legacy widgets, made some improvements on the custom gradient picker, worked on some PR reviews, continue the work around having configurable inner block settings to allow a parent block to absorve the child, and continued the iterations on some PR’s I had open.
  • For the next week, I’m hoping to merge the simulated media queries mechanism; I want to get involved again in the navigation block work, so I hope to do many reviews there and maybe pick up some tasks, besides that I will continue the buttons block and innerblocks UI work.

@tellthemachines

  • For task coordination: I’ve mostly been reviewing nav-related PRs this week and will be away from the 14th to the 24th November. (In case anyone wonders why I’ve gone strangely silent :D)

@noisysocks

  • I’m still looking at nav-related PRs and working on the Welcome Guide as time permits.

@gziolo

@youknowriad highlighted the new Storybook available at: http://wayback.fauppsala.se:80/wayback/20191117163844/https://wordpress.github.io/gutenberg/

It is also important to note for people reading this async: it is possible to participate on the task coordination by commenting on the agenda.

Open floor

  • Embedding Multilingual ability as standard core functionality: seems a bit early for implementation but it’s definitely being considered.

Let’s review more PRs!

Just a note to everyone. Do please also spend a little time going through older PR’s. As there are many just hanging waiting for a comment, a review etc. We’re definitely falling behind in terms of reviews.

The number of open PR’s increasing which in part is a good signal it means the project is getting more interest, but we should try to review these PR’s as soon as possible so new contributors keep the interest in contributing and we get the features/fixes sooner.

#core-editor, #editor-chat

Editor Chat Agenda: 13 November, 2019

Note taker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, 13 November, 2019, 08:00 AM EDT.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • WordPress 5.3
  • Gutenberg 6.9
  • 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.

#agenda#core-editor#editor-chat

For task coordination: I’ve mostly been reviewing nav-related PRs this week and will be away from the 14th to the 24th November. (In case anyone wonders why I’ve gone strangely silent :D)

Task coordination: I’m still looking at nav-related PRs and working on the Welcome Guide as time permits.

For Task Coordination: Development of build in core functionality — Embed Multilingual ability as standard core functionality. I would like WordPress to have a built in multilingual ability to manage translated front end content, i.e. not just switching between different back-end languages. I would be surprised if this topic has not yet been discussed by the core team, as it is crucial for the success of any CMS in a more internationalised environment. The present plugin solutions are way too complicated, trust me. I have tried many of the most popular ones, and multilingual core functionality would give huge benefits on many levels through a tight integration into the CMS core. Just a thought. Rgds/Gunnar

For the open floor section, planning to bring up http://wayback.fauppsala.se:80/wayback/20191117163844/https://github.com/WordPress/gutenberg/pull/18454 for comments, the PR I opened to make the native mobile JS unit tests mandatory to pass on Travis, including instructions on how to debug them when needed.

Task coordination:

Some folks asked to move the meeting by one hour. Let’s discuss that in the meeting.

I’d also like to highlight WordPress 5.3 and Gutenberg 6.9.

Javascript Chat Summary – November 12, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Switching to Prettier

Slack | Github Issue

Some discussion ensued on what is needed to merge this pull.

  • Post on make.wordpress.org regarding any code standard changes affected by this pull (and to inform about the change). This will need further feedback from core lead devs, core committers and contributors.
  • There are some rule removals from the es-lint plugin package, some discussion ensued about how to handle that and are those changes necessary. At a minimum, there seems to be some agreement that the ESLint rules should match the standards.

Tasks:

  • Check how many of the existing eslint rules could stay unmodified and what can be tweaked to work with Prettier and which need to be disabled. Should align with whatever standards are for the project (including any necessary modifications to those standards)
  • We should also seek a way so that the eslint plugin can continue to be used without prettier so folks can have the benefit of styling standard checks the same way as of today.
  • Once the above is done, write a post on make.wordpress.org/core outlining the changes and inviting feedback.

__experimentalCreateInterpolateElement

Slack | Github

This is a new function that makes it possible to interpolate elements within a translated string and have those rendered as react elements. Currently, doing something like the following can’t be done in react.

1
2
3
const MyLinkComponent = ( { href } ) => {
    return wp.i18n.__( 'This is a <a href={ href }>link</a>' );
};

In order to have <a> render, you’d need to split up the string, which in turn breaks context for translations. The solution is __experimentalCreateInterpolateElement:

1
2
3
4
5
6
const MyLinkComponent = ( { href } ) => {
    return __experimentalCreateInterpolateElement(
        wp.i18n.__( 'This is a <a>link</a>' ),
        { a: <a href={ href } /> }
    );
};

If you have any feedback or concerns with the proposed api please give feedback in the pull.

In the meeting:

  • generally seems to be approval around the api
  • concerns over whether the parsing should be cached.
  • wondering whether there’d be value in introducing a useInterpolation hook (that could also take care of some of the caching)
  • adding some sort of performance testing (although since it’s not used anywhere, there’s nothing currently in the project that can help with this).

Upcoming React Features

Slack

In this portion of the meeting there was mostly just some resource and link sharing around upcoming react features:

#javascript, #meeting-notes

WordPress 5.3 RC 5

The fifth release candidate for WordPress 5.3 is now available for testing.

WordPress 5.3 is currently scheduled to be released on November 12 2019.

There are two ways to test WordPress 5.3 release candidate 5:

For details about what to expect in WordPress 5.3, please see the first,  secondthird and fourth release candidate posts.

Release Candidate 5 contains some bug fixes for the new default theme, Twenty Twenty – for reference, see #48557 – and addresses the following tickets:

  • #47708 – 5.3 about page
  • #48312 – Fix a typo in an inline comment
  • #48542 – In wp_default_packages_inline_scripts(), make sure the root URL middleware is registered before using the media middleware
  • #48543 – Comments: check if comment form element exists before adding a key handler to detect the cmd/ctrl-enter key press.
  • #48517 – Bundled themes: several changes to ensure consistency and accuracy for default theme headers
  • #48518 – Upload: When an image was scaled because it is larger than the big image threshold, use the originally uploaded image’s dimensions in wp_get_missing_image_subsizes(). Fixes an edge case/inconsistent behaviour when a registered image sub-size is also larger than the big image threshold.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.3 and update the Tested up to version in the readme to 5.3. If you find compatibility problems, please be sure to post to the support forums so we can figure those out before the final release.

The WordPress 5.3 Field Guide has also been published, which details the major changes.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

#5-3, #testing

Media Meeting Recap – November 7, 2019

The following is a summary of the weekly media component meeting that occurred on Thursday, November 7, 2019. Weekly media meetings are held every Thursday at 14:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @joemcgill , @mikeschroder, @afercia, @desrosj, @dinhtungdu, @karmatosed, @greglone, @azaozz

Meeting Time Discussion

It’s that time of year again (for some of us!) Fall Daylight Savings Time historically makes the meeting time move forward one hour. The next meeting will take place Thursday, November 14, 2019 at 02:00 PM UTC.

There was discussion in a group message consisting of meeting facilitators around potentially doing a rotation of one week at a convenient time for each side of the planet. The Hosting-Community room does this and it seems to work very well. This would allow for participation from groups outside of the normal hour that we hold the meeting while also allowing folks that have been stretching outside their normal work hours to catch the meeting async. Please let us know in the comments what you think about this! There was mention of potentially doing a few months on one schedule and a rotation after. Another suggestion was around doing many meetings instead of rotating meetings. This would entail two designated meeting times a week in an effort to encourage new participants. This topic will be discussed in the next Media Meeting. Any additional ideas would be appreciated.

WordPress 5.3 Tasks

There were three tickets discussed in the meeting.

  1. #48518 Inconsistent behavior when a registered image size is larger than the big image threshold – Testing is being done around this issue and should be ready for 5.3.
  2. #48451 Regression: wp_update_attachment_metadata filter now fires very often and without complete metadata – The Follow Up Post around this outlines a few areas to focus on with the recent uploads changes. Some discussion took place around whether or not a new hook would help folks adjust to the changes. This is still to be determined.
  3. #48522 Attachment size not generated when large images uploaded – A few more details about this issue can be found at this Slack Link. Testing would be appreciated on this ticket.

Feedback

If you have any feedback on the above, please feel free to leave a comment, join in #core-media for a chat, or attend the next meeting on Thursday, November 14, 2019 at 02:00 PM UTC!

#core, #core-accessibility, #core-media, #media, #summary

I’m a fan of “many meetings” with low pressure for folks where the time doesn’t align conveniently. I think keeping the Thursday meeting the same and adding a new day that aligns to the other side of the time zones would be great!