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

WP Notify weekly meeting agenda for Monday 10 February 2020

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

Agenda

  • Opening and welcome
  • Reviewing and updating the requirements document: Use Cases
  • Reviewing and updating the requirements document: Current Status
  • Open floor

We will continue by focusing on one or two sections of the requirements document. First we will review “Use Cases”, then we will move onto “Current Status”.

Due to a small misunderstanding on my part with the Slack notifications system during last week’s meeting, we’ll also allow a few minutes for any specific feedback to the Objectives section, before considering that item closed.

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

What does it mean to be a component maintainer? A refresher

For the purposes of contributing, WordPress [Core] is organized into a few dozen components. These are well-defined, functional areas.

The Core Website

Each of these components needs at least one maintainer – someone who will manage its health and represent its interests at important phases of the release process.

A maintainer does not have to be a senior engineer, but it would help to be fluent enough in PHP and JS to write a patch in an emergency.

At this writing (early 2020), Core has roughly 40 components (some with sub-components, for more granularity) and nearly 70 maintainers. A number of those maintainers have deep, overlapping interest in several areas, and they likewise help maintain several components.

What does a component maintainer do?

Writing code is likely the smallest part of the maintainer’s job. More of the role is stewardship: making sure the component works well in the larger context of WordPress Core.

Specifically, as a maintainer, you will:

  • Triage new tickets in your component
  • Help move existing tickets forward
  • Bug gardening
  • Spearhead bigger tasks
  • Mentor new contributors
  • Propose new features, and new ways of thinking about how your component works with the whole
  • Curate roadmaps
  • Work with other contributors and components for a better WordPress

Your role in a release

At the start of planning for every release, component maintainers get a chance to show the release team what new features they’re working on –and which of those features they believe they can reasonably have ready to commit by Beta 1 of the release.

Shepherding tickets

is a huge part of the maintainer’s role. It means you make sure a ticket describes an issue clearly, accurately and in enough detail to suggest possible diagnoses, and you encourage people to add patches, discussion, testing and feedback to the ticket.

In short, you play a major role in getting as many eyes as possible on as many tickets as possible, which gets them solved and moves the project forward.

How much experience do you need to become a maintainer?

The main thing is a passion for your component. That’s even more important than being a super-expert in it, because if you love it, you’ll learn all you need to know.

You also, therefore, need to read the documentation and ask if something is not clear.

You do need to be able to code for the specific component you want to be involved with. But, again, you don’t need to be a senior engineer – though if you can do some project management and people wrangling, you’ll be ahead of the game.

The component I want to be part of already has people

There is no set number of maintainers for each component.

Longtime maintainers with a deep understanding of particular areas of core are always looking for people to mentor. They want to get more people involved and share their knowledge.

In fact, the more the merrier! So come share the workload and have some fun.

I’m already a maintainer, but I can’t dedicate the time right now.

It’s OK! Another thing that’s important: ask for help when you need it.

If for any reason you can’t devote the time you used to, whether for now or forever, please say so. Other people might be willing to step up, so things don’t stall for too long.

You can stay on as a maintainer, or you can ask to be removed from the list: it’s totally your choice.

I am already a maintainer, but I feel I need to become a committer to do a better job …

… or maybe I just need to recruit a committer, so we can move things along faster in my component.

Being a maintainer and a committer are two separate things! Completely. They require different skills, different levels of knowledge of the project, experience, activity.

Of course, they’re not mutually exclusive. But becoming a committer follows a different procedure, and ultimately commit access comes from Matt.

If you champion your component with appropriate vigor, you’ll get committers. Because your tickets will have had the eyes, the patches and the total attention they need to move along.

All right, I’m convinced!

I want to be a maintainer. Where do I sign up?

Do any of these three:

  • Leave a comment on this post with your questions or your availability
  • Ping the existing maintainers
  • Attend the Core chats: there is a Component Maintainer section, and other attendees can help.

Thanks for making WordPress!

Dev Chat summary – February 5, 2020 (5.4 week 4)

The chat was facilitated by @davidbaumwald on this agenda.

Full meeting transcript on Slack

This devchat marked week 4 of the 5.4 release cycle.

Highlighted posts

Upcoming Releases – 5.4

We are currently in week 4 since WordPress 5.4 kick-off.

Further informations:

@audrasjb pointed out that it would be good to add more bug scrubs to help ticket triage and punting when necessary, to help contributors to focus on tickets that are realistically going to land in 5.4.

In addition to the scrub he scheduled for early Friday morning and Monday, @davidbaumwald will host another on Sunday.

Reminder: Beta 1 is the deadline for Feature Request and Enhancement type tickets. The full list of such tickets can be found with this Trac query.

Gutenberg Navigation Block

@noisysocks noted that including this block in the release could generate confusion for end users, as it will appear as a standalone block without any of the accompanying features (Full Site Editing and a new nav-menu.php page) that will make this block actually useful. He felts unsure if we want to remove this block from the 5.4 scope or not.

@jorgefilipecosta agreed with the concerns being raised by Robert. He said he was operating under the assumption that the navigation block needed to be part of 5.4. But from his side, he think we can change that assumption. He also think the navigation block by itself without Full Site Editing is not very useful for most users.

Note: the Navigation Block was officially removed from the release scope two days after the dev chat.

Plugins & Themes Automatic Updates

For reference, see the two related Trac tickets: #48850 and #49199.

@audrasjb updated the current work on the related tickets:

  • Technical aspects of the feature still need a lot of review from deeply experimented core committers
  • Design changes need to be validated by the design team

According to @audrasjb, there is a quite solid basis, but the Core team still needs to take some decisions about this feature, as we are approaching beta 1.

@desrosj made a deep review of the technical changes, and shared his concerns about the feature and also an alternative patch.

@mapk, @karmatosed and @audrasjb iterated on the user experience and their work is close to be finalized.

Email notifications are handled by @desrosj and will need copy review. @marybaum is available to help on that side.

The release Team will take the final decision about implementing automatic updates for Plugins & Themes in WordPress 5.4 before Beta 1 is released, and will publish a post on Make/Core to announce their progress on this specific topic.

#5-4, #auto-update, #gutenberg

Navigation block exclusion from WP 5.4

After plenty of great discussions about the Navigation block recently, the Gutenberg Team, including Dev Lead @jorgefilipecosta and me ( I’m the Design Lead), has decided not to include it in the WordPress 5.4 release.

We’ve been sharing this decision with the Release Squad for 5.4 and among many seasoned contributors to get a perspective on how everyone felt about this. The general consensus: people understand why the Gutenberg Team has made this call, and they support the decision.

Navigation block

Historical context

The Navigation block was a priority project for 2019. It was also planned for the WordPress 5.4 release. So we absolutely did not make this decision lightly. Ultimately, we recognize that although the block itself is ready to merge into Core, the Gutenberg Team believes this move is premature.

Why?

As I said, the Navigation block is usable right now. But we don’t think it’s useful yet – at least not until it has an intuitive place to live.

It’s hard to imagine cases where users would want to add a Navigation block to the post or page content. It’s much more likely that a given user would want to add a Navigation block to Header or Footer block areas – maybe even a Sidebar. However, that functionality in Gutenberg just isn’t ready.

Now, let me add this: if a user does want a set of links in a page, the new Buttons block in WordPress 5.4 can probably meet that need.

Buttons block

As I look back at the WordPress Project’s to-do list for 2019, the Navigation block didn’t exist in a vacuum. There was also the matter of Themes registering content areas which is still in progress as we speak. Both of those should co-exist and be released together. To include the Navigation block without a proper home isn’t really useful for users, and it doesn’t seem to justify a feature mention in the 5.4 release.

Going forward

Our next steps include adding a few more features to the block:

  • Creating a new page from within the block (19775).
  • Creating a Navigation block based on existing menu structures (18869).
  • Indicating “current” menu items visually (20076).

So that’s what’s happening with the Navigation Block and WordPress 5.4.

I want to ask you, personally, to join us in Core and in the Gutenberg Team discussions and give us your thoughts. Please review this block, to help further testing around it.

I’ll be picking up usability testing for this block again soon, and I’m looking forward to hearing from you how we can improve it.

And don’t forget to install the Gutenberg plugin to test the Navigation block in near-real-world conditions. With your feedback, we can make this block a great success.

#5-4, #gutenberg

Release Model Working Group Chat Summary: February 5th, 2020

Here is the Summary of the second Release Model Working Group Chat in #core on Slack at 20:00 UTC!

Thank you to @sergeybiryukov for the peer review on these meeting notes!

The Release Model Working Group was kicked off last week, with these goals in mind: 

  • Evaluate the technical changes needed to speed up the release process.
  • Evaluate if those changes are doable with the existing resources and tools.
  • Produce factual, objective documentation outlining the group’s findings.

Folks are welcome to self-assign areas of interest, which are outlined in this spreadsheet.

A GitHub repo has been created for the project, and there are a few open issues for the group to get started with. Here are some areas the group will focus on:

Next Meeting

Meetings for the working group will take place on the first and third Wednesday of the month at 08:00 UTC and 20:00 UTC. The next meeting is on Wednesday, February 19th, 2020. Hope to see you there!

 #release-process #meeting-notes

WP Notify Meeting Recap – February 03 2020

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

This was a very quiet meeting, with only @psykro and @hrmervin attending. We continued along with the planned items in the requirements document.

The Objectives section seems complete, and no one has added any further comments on the document or the recap post, so we’re going to move forward and accept this as it stands

We reviewed the current status of the new Use Cases section. @psykro added a comments on the State item as well as comments around how we see notifications being sent to users based on their role.

Based on the fact that there were no other voices in the meeting, we ended the meeting early. As always we welcome feedback from the community in the current progress of finalizing the requirements document.

Next Slack Meeting

📅 Monday, February 10 @ 14:00 UTC

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

Agenda: Release Model Working Group – February 5, 2020

Following last week’s kickoff meeting, here is the agenda of the chat happening later today: Wednesday, February 5, 2020, at 08:00 PM UTC.

The group works on a self-organized basis, but there are some things to agree upon all together as per last week chat’s recap:

  • Schedule planning regarding adoption of tasks
  • Next Steps towards research and documentation in GitHub

Thanks!

#release-process

What’s new in Gutenberg? (5 February)

More than 51 contributors participated in this exciting release.

It introduce some handy color related features to the Group and Columns block. Instead of changing the text color block by block you can now wrap a group blocks in a Group block and assign the base color to the parent block.

For consistency with the Navigation and the buttons block, the Link UI has been updated in the RichText formats.

This is also an exciting release of the block authors, we now have an official tool to scaffold blocks quickly. It’s as easy as running npm init @wordpress/block locally.

7.4 🇰🇷

Features

  • Add background color support to the Columns block. 17813
  • Add text color support for the Group block. 19181

Enhancements

  • Navigation Block:
    • Add submenu chevron indication setting. 19601
    • Save the ID to the destination entity. 18641
    • Select Parent Navigation Block after clicking “Create from all top-level pages”. 19817
    • Update Appender visibility. 19598 19846
    • Move the Link Settings panel. 19917
    • Improve the UX to add links. 19686
  • Multi-selection: don’t focus first selected block. 19762
  • Use the new link control component in the RichText link format. 19462
  • Copy: Apply sentence case formatting to panel titles. 19901
  • A11y: Add conditions and new translation strings for the BlockMover. 19757

New APIs

  • Add a new wordpress/create-block package for block scaffolding. 19773 19867
  • Add a new wordpress/icons package:
    • Introduce the package. 17055
  • Add a new wordpress/primitives package. 19781 19876

Bug Fixes

  • Prevent gallery images from creating undo levels as they load. 19937
  • FontSizePicker: Adjust Select Button size. 19479
  • Remove post title escaping. 19955
  • Fix Failure message styling in placeholders. 19673
  • Fix RTL styles for the Media Text block. 18764
  • Fix panel header styles. 19842
  • Fix the editor fixed position at the 960px breakpoint. 19970
  • Allow disabling color selection but keeping gradient support. 19925
  • Prevent crash when creating a hierarchical post without a title. 19936
  • Media & Text block: “Crop image to fill entire column” setting resets on image change. 19765
  • Prevent Alt+F10 from scrolling to the top. 19896
  • Fix clearing multi-selection with side click. 19787
  • Update hover and focus selectors for “Move to Trash” to ensure the link is always red 19974.
  • Popover component:
    • clean up requestAnimationFrame. 19771
    • fix typo causing the mobile inserter to go out of view. 19978
  • Fix bug in block multi-selection causing Rich text editing to be disabled. 19839
  • Fix useSelect React hook timing and rerendering issues. 19286
  • Core-data: do not publish outdated state to subscribers during updates. 19752
  • LinkControl component (Navigation and buttons blocks):
    • Initialize inputValue state from value prop. 19737
    • Handle submission via form handler. 19651
    • Use URL as a link when title empty. 19739
    • Prevent focus loss in edit mode toggle. 19931
    • Resolve error when value is undefined. 19856
    • Handle Popover onClose for LinkControl. 19885

Experiments

  • Add AnglePicker Component and useDragging hook. 19637
  • Add Global styles CSS variables generation mechanism. 19883
  • Allow blocks to register variations that shows-up in the inserter. 19243
  • Block Directory: Refactor the reducer by breaking out the block management actions into their own reducer. 19330

Documentation

  • Add docs for LocalAutosaveMonitor and __experimentalUpdateLocalAutosaveInterval. 19915
  • Add markdownlint script to lint docs markup. 19855
  • Add format-js detailed documentaation to wordpress/scripts package. 19946
  • Reorganize the Contributors Guide. 19853
  • Clarify when isEligible function is called. 19899
  • Typos and tweaks: 19833, 19914, 19736, 19759, 19869, 19802, 19813.

Various

  • Introduce Prettier Formatting:
    • Add the formatting script. 18048 19994
    • Format the codebase. 19963
    • Set a consistent line width. 19992
  • Automation:
    • Fix pull request merge automation errors. 19768
    • Run pull request automation on closed. 19742
    • Add a step that updates CHANGELOG files before npm releases. 19764
  • Allow Babel Stage 4 features. 19831 19065
  • Use a Link to the changelog instead of adding it inline in the plugin README. 19761
  • Use require.resolve() in wordpress/jest-preset-default config 19957.
  • Fix multi-selection intermittent e2e failure. 19865
  • Add Placeholder component to Storybook. 19734
  • Include block.json files in the plugin build output. 19786
  • Rename patterns to variations in the Block API. 19966
  • Paragraph block:
    • remove min-height. 19835
    • remove unnecessary CSS after shortcuts removal. 19821
  • Refactor ObserveTyping as function component. 19881
  • Move the is-navigate-mode classname to the WritingFlow component. 19868
  • Block: use React context to provide the selected element. 19782
  • Remove dead is-hovered selectors. 19870
  • Remove the editor dependency from the block library. 16160
  • Remove an unnecessary import from the playground. 19893
  • Refactor the RichText wrapper to use React hooks for wrapper component. 19095
  • RichText API: Limit “prefix” transformations to Paragraph blocks. 19727
  • Apply width-based modifier classes to Placeholder only when the width is known. 19825
  • Various:
  • Refactor the server-side rendering of the Navigation block. 19989 19991
  • Fix server-registered fixtures script. 19884
  • Remove the RichText is-selected class. 19822
  • Testing: Use deterministic selectors for incremented IDs. 19844

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 7.4.0 5.037s 34.54ms
Gutenberg 7.3.0 5.461s 34.63ms
WordPress 5.3 6.631s 71.553ms

#core-editor, #editor, #gutenberg

Editor chat Summary: 5th February 2020

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 5th February 2020 held in Slack. Moderated by @andraganescu.

WordPress 5.4

Gutenberg is getting ready for the incoming WordPress 5.4 release. This board should be a good summary of the current WP 5.4 project. @youknowriad mentioned that the beta1 is due next Tuesday, and it means feature-freeze.

So all features that should go in WordPress 5.4 should land this week (3rd – 7th Feb 2020) or wait for WP 5.5.

Gutenberg 7.4

If all goes as expected, the stable release should be published a bit later today, 5th February 2020.

Amongst the new updates it will include, a few highlights:

  • added shippedProposals to babel-env options
  • Navigation block’s submenus now have a chevron display option
  • background colour support to the Columns block
  • over 25 bug fixes and more than 80 documentation and other various updates

Weekly Priorities

Our short term general priorities remain:

  • Landing the Gutenberg 7.4.0 release
  • Getting Gutenberg ready for the WP 5.4 release

The February, “What’s next in Gutenberg” post is up!

Task Coordination

@nosolosw

I’ve continued the work initiated by @jorgefilipecosta and consolidated the overall Global Styles data proposal in this PR 20047 While waiting on reviews, I’m going to focus on putting together a PR to demonstrate how this data would be used client-side.

@youknowriad

I’ve been working on a few things:
– Priorities post
– WP 5.4 patch (e2e testing)
– Continue my icons package refactoring
– Allow third-party keyboard shortcuts registration
I expect to continue on some of these (icons, WP 5.4) and maybe rework on the G2 branch and land it after WP 5.4 beta1

@aduth

I’ve been focused largely on trying to land things in time for WordPress 5.4 beta. Right now mostly around: The new link editing UI, columns resizing improvements. I sort of hoped to get something with “sticky” preferences using user meta, but that one might slip, based on how the discussion around it is unsettled.

@get_dave

Working on the ability to create Pages within Nav Block, in PR 19775 

@andraganescu

I have been working on:
– the PostAuthor block 19894 – this could use a review, and some design eyes cc: @mapk
– pushed with @jorgefilipecosta a fix for the rendering the Navigation block in core
– tinkered more with always-on URL showing in the MediaReplaceFlow component 19504 – a bit stuck on wether to use the LinkControl or move along with the older controls

@karmatosed

I am deep in the global styles world with a side order of triage. Lots of interesting thoughts bouncing around: 19255 This week I am going to be exploring if we need more tools for global styles, interface beyond side and also try and create some things with the tools we are suggesting.

@itsjonq

Also deep in Global styles work, alongside @karmatosed, @nosolosw, and @jorgefilipecosta
Mostly planning and coordinating. Also helping with Design x Dev explorations with @karmatosed on the UI

@mcsf

I’m focusing on the reimplementation of Social Links using the new Block Variations API (19887). Should be good to go.
Other focuses concern 5.4: little items needing core patches, etc. 

@mapk

– Helping to wrangle PRs for WP 5.4
– Providing feedback on Columns block work
– Moved reusable blocks link to Block Manager

@retrofox

We keep working on Navigation improvements in general. One of the most important was the implementation of the new design of sub-menus:
19681. It makes the Navigation really better especially in terms of UI.

Also, we tried to consolidate the styles for both front-end and editor-canvas in a single file in order to make them as similar as possible. among other improvements.
Here is the navigation dashboard, just in case.

@tellthemachines – from the agenda comments

I have been working on a fix for a few columns styling issues, and aiming to make the columns block compatible with the above editor resizing functionality. The PR is 19297

Open Floor

First @aristath raised attention on 19993, which is an important addition to the Navigation block. Also he mentioned the meeting in #theme-review starting soo, agenda here.

We had a few things from the agenda comments for the open floor.

@paaljoachim highlighted pr 20015 about where to place the caption alignment button. Following a discussion between @mapk, @youknowriad, @epiqueras and @jeffreycarandang  more discussion will be held in the PR.

Also @paaljoachim highlighted pr 15102 and Trac ticket 49185 about optionally not embedding links to another WordPress site. Many people approved @mcsf ‘s suggestion to “combine the undo behaviour with a timely snackbar notice”.

@tellthemachines had three things for the open floor, from the agenda comments.

1st is that the resizable editor work in 19082 is now complete and in need of code review.

2nd was the new public facing API of adding CSS markers to define where to start and where to end media quert manipulation. @youknowriad asked if we should wait with this feature until WP 5.5 beta 1 and not launch it as part of WP 5.4.

Probably @tellthemachine ‘s offer to write documentation/blog post explaining how it works will draw even more attention and help deciding when to include the feature.

3rd is that there’s going to be a CSS meeting!

To discuss evolving standards, new tools and best practices join the CSS meeting on the 13th February, 9pm UTC. All details here.

The CSS meeting announcement had many positive reactions 🙌

On a final note, @jorgefilipecosta raised the new discussions happening around global styles and how those might affect they way we simulate styles and hence how the resizable editor works. @youknowriad suggested that he seeks @tellthemachine ‘s input on those global styles discussions.

<-- /meeting: 5 February 2020 -->

Final note

If you want something discussed during the next #core-editor meeting, on Wednesday, 12th February 2020, 2pm UTC do one of:

  • add it to this agenda document
  • or add a comment below
  • or comment on the meeting agenda post once it’s published.

Thank you and keep up the good work!

#gutenberg, #meeting-notes

Dev Chat Agenda for February 5, 2020 (5.4 Week 4)

Here is the agenda for the weekly meeting happening later today: Wednesday, February 5, 2020, at 09:00 PM UTC.

Announcements

  • This week marks week 4 of the 5.4 release cycle 🙌

Highlighted Blog Posts

Upcoming Releases – 5.4

  • Additional bug scrubs leading up to Beta 1
  • Nav Block and Auto-Updates Progress Report

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

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-4, #agenda, #core, #devchat