Make WordPress Core

Keyboard Shortcuts | Hide comment threads
Tonya Mork 7:05 pm on December 21, 2020

Bug Scrub Schedule for 5.7

With 5.7 officially kicked off, time to schedule the 5.7 sessions. These 5.7 specific ticket scrubs will happen each week until the final release.

Early Scrubs:

Focus: early tickets, tickets that require more time or early testing.

Alpha Scrubs:

Focus: features and enhancements.

Beta Scrubs:

Focus: issues reported from the previous beta and defects.

RC Scrubs:

Focus: issues reported from the previous RC

Check this schedule often, as it will change to reflect the latest information.

APAC-friendly scrubs will be led by @lukecarbis.

What about recurring component scrubs and triage sessions?

The above 5.7 scheduled bug scrubs are separate and in addition.

For your reference, here are some of the recurring sessions:

  • Design Triage: Every Tuesday 16:00 UTC in the #design channel (for both core and Gutenberg).
  • Accessibility Scrub: Every Friday 14:00 UTC in the #accessibility channel.
  • APAC-friendly Scrub: Every Tuesday at 05:00 UTC in the #core channel. This scrub will continue during the cycle, alternating focus between core and editor.
  • Testing Scrub: Every Friday 13:30 UTC in the #core channel.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at anytime? Yes, you can!

How? Ping me (@hellofromtonya) on slack and let me know the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 5.7-focused? Awesome! We’ll add it to the schedule here. You’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub?

  • Report 5 provides a list of all open 5.7 tickets:
    • Use this list to focus on highest priority tickets first.
    • Use this list to focus on tickets that haven’t received love in a while.
  • Report 6 provides a list of open 5.7 tickets ordered by workflow.

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the core handbook.

Questions?

Have a question, concern, or suggestion? Want to lead a bug scrub? Please leave a comment or reach out directly to me (@hellofromtonya) on slack.

#5-7, #bug-scrub

Kirsty Burgoine 4:41 pm on January 29, 2021

# Introducing CSS Custom Properties…

Introducing CSS Custom Properties to the WordPress Admin

As part of the Iterating on Colour Schemes ticket (#49999) the #core-css team have been working on how to go about implementing the use of CSS Custom Properties in the WordPress Admin.

The first step of this task was to iterate on the existing colours used and reduce them down to a workable color palette. This work was committed to core on Tuesday January 26th 2021 thanks to the awesome work of @ryelle and the rest of the #core-css team. This reduced the number of unique colours used from 199 to 99!

The next step now is to look at how we can use this work to create a colour palette using CSS Custom Properties and ensuring we have all of the relevant fallbacks. This is where we would really like to invite some discussion (and is the point of this post).

From discussions we’ve already had on various tickets and during the #core-css meetings, there are a number of options currently being considered.

Naming Custom Properties

We all know naming is hard! However, there have been a number suggestions already that could be considered.

The colours already have names (see this codepen for an easy reference: http://wayback.fauppsala.se:80/wayback/20210129175837/https://codepen.io/ryelle/full/WNGVEjw) so we could continue to use the same names. For example:

1
2
3
4
5
-—color-blue-20: #72aee6;
—-color-blue-40: #3582c4;
 
—-color-green-20: #1ed14b;
—-color-green-40: #00a32a;

We could, instead of using the actual colour name, implement using primary, secondary, tertiary names. For example:

1
2
3
4
5
—-color-primary-20: #72aee6;
—-color-primary-40: #3582c4;
 
—-color-secondary-20: #1ed14b;
—-color-secondary-40: #00a32a;

There was also a name proposal for hues in this post: http://wayback.fauppsala.se:80/wayback/20210129175837/https://make.wordpress.org/design/2019/11/26/proposal-a-new-color-palette-for-wordpress/ which looked like:

1
2
3
4
5
6
7
8
9
--color-primary
--color-error
--color-warning
--color-success
--color-background: light gray background used in WordPress.
--color-surface: white background used for UI elements.
--color-border: border color used on UI elements.
--color-on-surface: default dark gray text/icon color.
--color-on-surface-subtle: light gray text/icon color.

Implementing CSS Custom Properties.

So far the general approach to this, that has generated the most discussion and agreement, is to create a base colour palette and then apply those colours to properties named after their usage. Something similar to:

1
2
3
4
5
6
7
8
9
10
11
// Base color palette.
—-color-gray-0: #f6f7f7;
—-color-gray-100: #101517;
 
// Properties used in CSS.
—-body-background-color: var( —-color-gray-0 );
—-text-default-color: var( —-color-gray-100 );
 
// Application.
body-background-color: var( —-body-background-color );
color: var( —-text-default-color );

(Exact property names and colours used here are examples only)

This would give us the flexibility to utilise the dynamic nature of CSS custom properties to change the value of properties based on certain criteria, and without the danger of the name becoming misleading or incorrect.

I imagine that, which custom properties should be created in the abstracted layer applied in the CSS, would generate a lot of conversation. However, if there are other ways to implement custom properties that you feel may be worth exploring as well, please do still mention them.

Additional Considerations

One of the overall goals of this work is to ensure the admin is inclusive to everyone by utilising some of the newer features coming to CSS and honouring peoples individual system preferences. At the moment the focus of this is honouring dark mode but more customisation options are becoming available so how we name custom properties and choose to implement them needs to account for that. For example, this wouldn’t be suitable because the name becomes misleading.

1
2
3
4
5
—-colour-black-background: #000;
 
@media (prefers-color-scheme: light) {
    —-colour-black-background: #fff;
}

The other big consideration is that there are a number of alternative admin colour schemes already available, all of which should be able to take advantage of the use of custom properties once implemented. Therefore we need to keep the number of custom properties created concise and how we implement them needs to easily extendable.

As well as this we do also need to consider fallbacks for browsers that do not support CSS Custom Properties and this could impact how we name or implement them.

Next Steps

There is a lot of options here that could be discussed and the purpose of this post is to start some of those discussions and invite you all to give your opinions. So if you have any thoughts on this please do add them here and/or join in the live discussions in the weekly #core-css meeting every Thursday from 10pm UTC.

#core-css

#00a32a, #1ed14b, #3582c4, #72aee6, #f6f7f7, #fff

Dan Farrow 11:13 pm on January 28, 2021

CSS Chat Summary: 28 January 2021

The meeting took place here on Slack – @notlaura facilitated and @danfarrow wrote up these notes

Housekeeping

  • @paaljoachim suggested that the bi-weekly core CSS bug-scrubs alternate between Trac tickets & Gutenburg Github issues
  • @tellthemachines agreed & suggested triaging issues under the CSS styling label
  • @notlaura suggested doing this at the next bug-scrub which is scheduled for 11th February

CSS Audit (#49582)

Color Scheming (#49999) & Visual Regression Testing (#49606)

  • @ryelle reported that her reduced colours PR has been merged into core
  • @ryelle has also published a PostCSS plugin & workflow that can be used by devs to automate the colour replacement
  • The number of unique colours has reduced from 199 to 98. @ryelle suggested that the next step would be to replace these with custom properties
  • This initiated a tricky-to-summarise discussion about naming which led into ideas of how to facilitate a wider discussion
  • @notlaura suggested a Make post inviting conversation, to align with global styles & editor design system initiatives. @tellthemachines agreed that a Make post would attract wider contribution, and @kburgoine offered to write the post

Visual Regression Testing

  • @tellthemachines reminded us that her PR is still open & has received some review feedback
  • She plans to add more tests in the coming week, followed by tests for mobile breakpoints
  • She is also considering the basis on which the tests should be automated with Github Actions

Open floor & CSS link share

Thanks everybody!

#core-css, #summary

Hong Nga Nguyen 8:53 pm on January 28, 2021

Media Meeting Recap – January 28, 2021

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

Attendees: @antpb, @paaljoachim, @hellofromtonya, @joedolson, @ricjcs, @audrasjb, @mista-flo, @mkaz, @chaion07

Open Floor

This meeting’s focus began with an open floor for discussion on outstanding tickets and issues members wanted to address.

#47839: Extended file management in Media Library – @ricjcs brought up this ticket containing design samples of what folders could look like in the media library. Discussion occurred around what this feature would entail from a backwards compatibility perspective.

#52372: Ability to Replace image on the “attachment details” screen – This feature has been explored and ultimately closed after this comment in #49096. Per @antpb, “This is another one where I don’t think it’s a bad idea, in fact, it’s great, but it’s very much in plugin territory to make the decisions for your individual site. What may be good for one site may not be good for all. Offering the ability to replace media by default offers folks ways to unintentionally break old content.”

5.7 Tickets

#52192: REST API: Add batch image editing – This ticket is currently in review with @antpb and is aiming to be committed before alpha. It was discussed that this endpoint is low risk as it does not impact any existing endpoints and adds new ones.

#50025: Media Library not showing new uploads when filtering by date – This ticket is currently in review after it was found to have issues with the classic block media flow. @antpb is testing and will be aiming to commit before alpha.

#39004: Alt attributes should be searchable in media library – This ticket was discussed as being close to ready for commit, but talks after the meeting indicate it may need further testing with larger media libraries.

#52387: adjacent_image_link returns a link with no accessible text – @antpb has given an initial review and is aiming to commit soon after more testing.

Bug Scrub

There are a number of enhancement tickets that still need to be scrubbed. A bug scrub has been scheduled for Monday, February 1 at 16:00 UTC to go over these tickets. Please join us if you would like to contribute!

Props @antpb for proofreading and final review.

#core, #media, #summary

Lara Schenck 8:08 pm on January 28, 2021

CSS Chat Agenda: 28 January 2021

Note: 1 hour before the meeting, @kburgoine will host the CSS bug triage!

This is the agenda for the upcoming CSS meeting scheduled for Thursday, January 28, at 10:00 PM UTC. This meeting will be held in the #core-css channel in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

  • Housekeeping
  • Updates
  • Open floor + CSS link share

#agenda, #core-css

planningwrite 7:42 pm on January 28, 2021

WordPress 5.6.1 RC1

WordPress 5.6.1 Release Candidate 1 (RC1) is available for you to test!

Here are two ways to test WordPress 5.6.1 RC1:

  • Use the WordPress Beta Tester plugin (select the point release nightlies option)
  • Download the release candidate here (zip)

What’s in this release candidate?

5.6.1 Release Candidate 1 features 20 bug fixes and small enhancements, as well as 7 bug fixes for the block editor.

WordPress Core changes on Trac:

  • #51056: Fetch_feed parsing of permalinks triggers simplepie preg_match warnings
  • #52327: Requested updates to the PHP Update Alert
  • #51940: The schema for the taxonomy property of a term in the REST API should not include all taxonomies
  • #51980: App Passwords: ‘Add New Application Password’ submit button is hidden on mobile devices in ‘User Profile’ page
  • #51995: WordPress 5.6: Classic editor menu is not sticky
  • #52003: Undefined index: PHP_AUTH_PW /wp-includes/user.php on line 469
  • #52013: Duplicate wp_authorize_application_password_form actions
  • #52030: Media metaboxes return fatal error if no author metadata present
  • #52038: Issue in WooCommerce with wp_editor() after update to WP 5.6
  • #52046: The Distraction Free Writing setting on the old Edit Post screen may be reset after page reload
  • #52065: Media gallery: ‘Align’ and ‘Link To’ fields missing from ‘Insert from URL’
  • #52066: Application Passwords are unusable in combination with password protected /wp-admin
  • #52075: Word Count on Classic Editor doesn’t update in real time on Firefox unless saved
  • #52097: Site Health Loopback Test doesn’t send admin cookies
  • #52135: False positive on `WP_Site_Health_Auto_Updates`
  • #52196: wp_get_attachment_metadata() is broken if no first argument is passed in.
  • #52205: REST API: Plugins Controller single plugin route fatal errors on multisite
  • #52299: Exported user data can be listed with directory listing
  • #52351: missing echo function for translate method
  • #52391: Gutenberg Updates for 5.6.1

Block editor changes from GitHub:

  • #27970: Fix editor crash when registering a block pattern without categories
  • #27733: Embed block: Add html and reusable support back
  • #27727: Add aria labels to box control component inputs/button
  • #27627: HTML Block: Fix editor styles
  • #27526: Core Data: Normalize _fields value for use in stableKey
  • #26705: Fix: Font size picker does not correctly handles big font sizes.
  • #26432: Edit Site: prevent inserter overscroll

What’s next?

The dev-reviewed workflow (double committer sign-off) is now in effect when making any changes to the 5.6 branch.

As per the proposed WordPress 5.6.1 schedule, the final release is expected for Wednesday, February 3, 2021, before or after the weekly devchat. Please note that this date/time can change depending on possible issues after RC1 is released.

#5-6-1, #minor-releases, #releases

adrian33000 8:59 pm on January 28, 2021

Regarding Site Health I personally feel the warning about auto-updates setting being “Critical” is a bit heavy-handed. There are many hosting companies and WP management companies that undertake updates as part of their service and clients seeing a “Critical” warning are going to wonder what that is all about and why it is there. A note lower down saying that auto-updating is “recommended” or “advisable” or “available” might be a more appropriate notification.

Monika Rao 10:19 am on January 28, 2021

Test Scrub for WordPress 5.7 and office hours

As part of the 5.7 release, we’ll be hosting a focused test scrub for the below-listed tickets, Tomorrow, Friday 29/01/2021 13:30 UTC in the #core channel on Slack.

http://wayback.fauppsala.se:80/wayback/20210129175837/https://core.trac.wordpress.org/ticket/51812
http://wayback.fauppsala.se:80/wayback/20210129175837/https://core.trac.wordpress.org/ticket/51941
http://wayback.fauppsala.se:80/wayback/20210129175837/https://core.trac.wordpress.org/ticket/52355
http://wayback.fauppsala.se:80/wayback/20210129175837/https://core.trac.wordpress.org/ticket/48562
http://wayback.fauppsala.se:80/wayback/20210129175837/https://core.trac.wordpress.org/ticket/47912

The ticket is ready to be considered for commit but needs testing/QA.

To set up the Testing Environment follow the steps listed here – http://wayback.fauppsala.se:80/wayback/20210129175837/https://meta.trac.wordpress.org/ticket/5581#comment:3

How to apply a patch

Trac ticket, for example 35449

npm run grunt patch:35449

How to fetch and then checkout a PR, for example, PR 828

git fetch upstream pull/828/head:pr-828
git checkout pr-828

or for PR:

npm run patch http://wayback.fauppsala.se:80/wayback/20210129175837/https://github.com/WordPress/wordpress-develop/pull/828

Check the handbook for more ways to test patches.

Do you have a ticket you want to bring up for testing?

Fantastic!

In order to allow testers to manually test the patch, you should include the following information:

  • What are the steps to reproduce the problem?
  • What are the steps to test?
  • Are there any testing dependencies such as a plugin or script?
  • What is the expected behavior after applying the patch?

#5-7, #test, #testing

Peter Wilson 3:38 am on January 29, 2021

It would be helpful if the latest patch for #5272 could be tested.

To recreate the bug in 5.6:

After applying the patch visiting the URL while logged out should not redirect.

Items to check:

Thanks folks.

Jb Audras 1:25 am on January 28, 2021

WordPress 5.6.1 maintenance release schedule

After WordPress 5.6 “Simone” was released, some tickets were opened reporting identified bugs, mostly concerning bundled themes.

Given the need for a fast-follow WordPress 5.6.1 release before the end of 2020 was ruled out as no tickets were identified as urgent, the WordPress Core Team decided to update Twenty Nineteen and Twenty Twenty-One Bundled Themes independently from WordPress Core.

Now, it’s time to merge these changes into a new WordPress minor release and to address the other tickets that have appeared in the meantime.

WordPress 5.6.1 milestone currently contains 22 bundled themes patches plus at least 23 other bugfixes reported after WP 5.6 was released.

The following release schedule is being proposed:

  • Release Candidate: Thursday 28 January, 2021 around 17:00-19:00 UTC
  • Final release: Wednesday 3 February, 2021, after the weekly devchat

The full list of the tickets targeted for this maintenance release is available on the 5.6.1 tickets report on Trac.

#5-6-1

Andrei Draganescu 4:42 pm on January 27, 2021

Editor chat summary: 27th January 2021

This post summarises the weekly editor chat meeting (agenda here) held on Wednesday, January 27, 2021 at 02:00 PM UTC in Slack. Moderated by @andraganescu

Gutenberg Plugin Release

  • Gutenberg 9.9 RC has been delayed for January 29th 2021, to sync with the upcoming beta 1 release of WordPress

WordPress 5.7 Beta 1

  • WordPress 5.7 Beta 1 is due for release on the 2nd February 2021.
  • Beta 1 will represent the cut-off point for new commits/features for the Block Editor.
  • The deadline for changes is Gutenberg 9.9 RC on the 29th January.
  • There is a WordPress 5.7 project board where you can follow along and keep up to date with progress.
  • WordPress 5.7 will include versions 9.3 to 9.9 of Gutenberg

Monthly Plan & Key Project updates

  • We requested updates on the key projects.

Full Site Editing

Global Styles

  • not many updates but issue 27506 is a good starting point to gauge GS status 

Block based Widget / Navigation Editor

@andraganescu provided an update for the widgets editor:

@mkaz added an update on the ongoing additions to the Navigation block:

  • The Navigation Block tracking issue is here, though we are also working on issues raised for items needed to help develop themes. So that list my get supplemented with a few additional issues. (edited) 

@grzim added an update about the navigation editor:

Task Coordination

@hypest provided a

short update about what the native mobile folks have been up to:

  • Reusable blocks rendered in-editor (only available in DEV builds for now)
  • Audio block close to merge
  • Fix for blocks auto-scroll when the keyboard appears
  • Fixes for issues resulting from some GB-web side changes
  • Fix for File block’s automated test.

@bernie will continue to work on some release tooling automation soon. Afterwards, there are two things on the automated testing front that I’d like to work on:

  • Run e2e tests in FF (draft PR).
  • Visual diffs (to avoid block regressions) (issue)
  • Anyone interested in helping with those? Experience with puppeteer would be especially helpful for the e2e tests!

@annezazu is working on the “What’s Next” post for February and the FSE program. For the FSE program, I’m trying to find creative ways for more people to help through sharing various roles for the program (helping write calls for testing, triage feedback, etc), updating documentation with more information about the process I’m loosely following/creating, and sharing an idea around how we can include polyglot communities! I wasn’t here to announce the how to triage in GitHub course is live on LearnWP too! Working on another course this week/next week for more GitHub basics 

@paaljoachim is Working on consolidating setup local dev environment + testing instructions for Gutenberg and core.
Triaging Design and Gutenberg issues.
Working on a Dev site for support structure. Experimenting with the design for Learn and more. 

@mcsh updates:

  • Fixed a fatal infinite recursion issue in Reusable Blocks (@gziolo now fixing the same in Template Parts)
  • Code reviews
  • Too many conversations to name, but recently: with @ella about Footnotes, with @ntsekouras about focus bugs and other issues related to React refs, @gziolo about how we do e2e testing, table of contents block, etc.

@andraganescu did mostly code review and testing on widgets and navigation editors

@joen has been working on a bunch of small navigation block user experience related things:

  • Menu item word wrap
  • URL cutoff
  • Menu item overflow menu polish
  • Button block appender
  • Space between

@itsjonq is Continuing his efforts to work on integrating the new Component System into Gutenberg (working on it directly as well as coordination). He is also tinkering with new UI tools for Gutenberg in parallel, focusing specifically on background/color tools at the moment.

@ntsekouras updates:

  • Lot’s of triaging and GH reviews with some fixes
  • `Preferences` modal is probably ready to merge (PR /28329) – thanks @joen for the styling polish there

Open Floor

Will there be Global Styles also in the Post Editor? Or is that only to be for the Site Editor?

The general consensus on @paaljoachim‘s question was that the post is a place which lacks enough visibility for the impact the changes would have so most likely the answer now is no.

What’s Next post for February

@annezazu brought up the next focuses:

  • Preparing for 5.7
  • Global Styles
  • FSE
  • Block-based Widget Editor

Global styles in WordPress 5.7

@mcsf mentioned that whatever pieces of GS that may land in 5.7, they will concern the theme.json structure and won’t impact users. At best, there will be experimental APIs that devs may use in Core, following in the footsteps of the well-known add_theme_supports extensions

AMA session about FSE and a dedicated FSE feature channel

@annezazu proposed to great enthusiasm an AMA session about FSE and also the creation of a dedicated feature channel for FSE.

A plan to standardize the use of feature channels

@priethor suggested a plan to standardize the use of feature channels:

  • Gather feedback on the overall feeling about these channels, whether folks think this segmentation improves communication or makes it more difficult.
  • If feature channels are agreed to be an improvement, create feature-specific channels for other feature projects such as FSE.
  • List these channels on the Feature Projects Overview page and promote them in automated welcome messages, as suggested by @annezazu.

@francina mentioned that “having multiple channels dilutes the attention of contributors, issues are not developed in a silo and are interdependent, so I am not sure having a myriad of channels is really helping, but willing to try”.

Internal Contributor Day at Yoast on February 5th

Also @francina mentioned:

We are doing an internal Contributor Day at Yoast on February 5th. Let me know if there are some PRs that need developers and/or users testing

This is a great opportunity to bubble up things in need of testing or extra development hands!

Input wanted on the editing of a menu’s name in the navigation editor

Lastly @grzim called attention on PR 25343 where editing a menu’s name is added to the navigation editor, for sharing opinions on the approach taken there to make it as user-friendly as possible.

Thanks to everyone who attended!

#core-editor, #core-editor-summary, #meeting-notes, #summary

Ebonie Butler 4:14 pm on January 26, 2021

Dev Chat Agenda for January 27, 2021

Here is the agenda for this week’s meetings to occur at the following times: Wednesday, January 27, 2021 at 05:00 AM UTC and Wednesday, January 27, 2021 at 08:00 PM UTC.

Blog Post Highlights

Next Releases

  • WordPress 5.6.1 (Release to be scheduled)
  • WordPress 5.7 (Upcoming Beta 1 Release in one week 🎉)

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

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

#5-7, #agenda, #dev-chat

Francesca Marano 4:53 pm on January 26, 2021

Hello! I would like to discuss the feasibility of branching at Beta 1 instead of RC1. Thanks!

Gary Pendergast 4:44 am on January 27, 2021

Following up on last week’s Importers discussion, the #core-importers channel now exists!

Francesca Marano 6:52 pm on January 27, 2021

During today’s bug scrub, we found out that there are 49 tickets in a component that doesn’t exist anymore: this issue leads me to believe that it might be time to revisit the components system and probably the maintainers’ role. Maybe something more like product owners, which will guide the development of the component while also check the backlog and make a decision about old tickets based on the current state of the project.
Thinking out loud here 🙂

Paal Joachim Romdahl 7:15 pm on January 27, 2021

I am working on consolidating setup a local dev environment + testing in relation to core and Gutenberg. http://wayback.fauppsala.se:80/wayback/20210129175837/https://meta.trac.wordpress.org/ticket/5581
I added a comment to the ticket with instructions for setup and testing used for core bug scrubs. I believe this is only for Mac/Linux. We need also need similar instructions for Windows. Can the existing instructions be ported over to a Windows OS? If not how would we proceed to update the instructions for Windows? (I am on a Mac making it tricky for me to update these instructions.)

Paal Joachim Romdahl 2:38 pm on January 26, 2021

Editor Chat Agenda: 27 January, 2021

Facilitator and notetaker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, January 27, 2021, 03:00 PM GMT+1.

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

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • 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, #core-editor-agenda, #meeting

annezazu 4:15 pm on January 26, 2021

I’ll be at the meeting but just wanted to share my items ahead of time as I have a few for open floor!

  • Working on the “What’s next” post for February and would love to get input there to make sure I’m not missing anything major.
  • What items feel ready for testing for the FSE Outreach program? I’m keen to have another call for testing lined up ASAP.
  • (If there is time) Is it time for a feature slack channel for FSE? With channels for navigation and widgets, it came to mind. Plus I’m noticing feedback in the FSE outreach program channel that would best belong in a place like that. Right now, pushing people to the core-editor channel 🙂
Robert Anderson 12:51 am on January 27, 2021

Some 5.7 related things to share:

  • WordPress 5.7 Beta 1 is due next week on Feb 2
  • WordPress 5.7 will include versions 9.3 to 9.9 of Gutenberg
  • Work has begun on updating Gutenberg packages in Core
  • I recommend that we delay Gutenberg 9.9 RC until the end of this week (Feb 29) so that these enhancements can land in time for 5.7 Beta 1: #28318, #25892, #28329, #23636
priethor 10:11 am on January 27, 2021

I would like to raise a topic during the open floor section: increasing the visibility of feature-specific Slack channels.

Francesca Marano 1:57 pm on January 27, 2021

Hello!
On February 5th, 2021, we will be having an internal contributor day at Yoast contributor day. The focus will be testing as much as we can with different skillsets.
Are there specific issues you need to be tested by developers? By end-users?
We would love to help! Thanks