David Baumwald 6:32 pm on January 20, 2020
Tags: ,   

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

Jb Audras 9:51 am on February 12, 2020
Tags: ,   

Formal deprecation of some unused Customizer classes in WordPress 5.4

WordPress 4.9 deprecated the WP_Customize_New_Menu_Control and WP_Customize_New_Menu_Section PHP classes and wp.customize.Menus.NewMenuControl JavaScript class. The Core Team initially planned to remove them entirely in WordPress 5.0.

Deprecated items

Given how much time has elapsed since then, WordPress 5.4 leaves in place WP_Customize_New_Menu_Control and WP_Customize_New_Menu_Section to prevent potential backwards compatibility issues. 5.4 also formally deprecates them using _deprecated_file() and _deprecated_function() calls.

As a reminder:

_deprecated_file() is used to mark a file as deprecated and inform when it has been used. There is a deprecated_file_included hook that can be used to get the backtrace up to what file and function called the deprecated function. The behavior is to trigger an error if WP_DEBUG is true.

_deprecated_function() is used to mark a function as deprecated and inform when it has been used. There is a deprecated_function_run hook that can be used to get the backtrace up to what file and function called the deprecated function. The behavior is to trigger an error if WP_DEBUG is true.

Removed item

WordPress 5.4 removes the wp.customize.Menus.NewMenuControl JS class completely. This JS class can’t be used anymore starting with WP 5.4.

For reference, see the related Trac ticket: #42364

#5-4, #dev-notes

itsjusteileen 1:12 pm on February 11, 2020
Tags: , , ,   

Editor Chat Agenda: 12th February 2020

Note taker: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, February 12, 2020, 09:00 AM EST. This meeting is held in the #core-editor WordPress Slack channel.

Highlighted Blog Posts

Discussion Topics

  • WordPress 5.4 Upcoming Release
  • Exclusion of the Navigation Block from the 5.4 Release
  • Gutenberg 7.5.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.

#agenda, #core-editor, #editor-chat

#editor

tellthemachines 5:34 am on February 11, 2020
Tags: ,   

CSS Chat Agenda: 13th February 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, 13th February, 9pm UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

Agenda:

  • Welcome
  • Setting standards for use of new(-ish) CSS features: grid and variables
  • Looking at tools to improve our workflow: CSS-in-JS
  • Open Floor

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-css

Jonathan Bossenger 6:29 am on February 10, 2020
Tags: ,   

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

Francesca Marano 10:03 pm on February 9, 2020  

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!

Jb Audras 11:44 pm on February 8, 2020
Tags: , ,   

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

Mark Uraine 10:02 pm on February 7, 2020
Tags: ,   

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

Amy Kamala 11:55 pm on February 6, 2020
Tags:   

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

Jonathan Bossenger 10:14 am on February 6, 2020
Tags: , ,   

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

Amy Kamala 7:42 pm on February 5, 2020
Tags:   

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