agm

Why I voted to delay WordPress 5.9

If you haven’t heard the news yet, WordPress 5.9 has officially been moved and is set to ship on January 25th, 2022. You can see the updated full schedule here. 

I’m on the release squad for the first time and wanted to share more about why I voted to delay. My hope is to bring you all along for the decision making process and to demystify how this decision came to be. To set context, I’m the Test co-lead and am helping the Docs leads with user documentation. I’ve also had the opportunity to run the FSE Outreach Program for the last year and a half, introducing me to a wide range of people and bugs/feature requests in the software itself. This program is dedicated to gathering feedback, building awareness, and growing people’s ability to create with full site editing features. With a lot of the full site editing features we’ve tested landing in 5.9, I have deep knowledge of the state of these features and how they’ve evolved. 

What triggered a decision process? 

A group of core contributors did a thorough test of trunk the week of November 15th leading to a comprehensive list of issues to address. This collection of feedback came in right before the planned beta 1 release date of November 16th. While we can’t always predict the timing of things, it is very good that this feedback came in and shows the resiliency of the WordPress community that it was embraced.

Based on the feedback from that test, it became clear that some decisions needed to be made around how this would impact the release. For more context on this decision process, factors that influenced it, and what the possible options were, please check out the Make Core post detailing how the release squad handled this. 

Factors that influenced my vote

At a high level, there are four main reasons why I voted to delay, even though it meant shifting the release from mid-December to late January:

  • Delaying improved sustainability for contributors after a wild, long year, especially given the timing of larger cultural moments coming up at the end of the year/beginning of the year in areas where we have a large number of contributors. 
  • Interrelated features of full site editing make it hard to punt or fully remove pieces.  
  • The value added to users when getting access to the whole suite of full site editing features, rather than smaller pieces.
  • Most of the raised issues would refine the experience rather than redefine it (more on that later). 

More specifically, if we were to push everything to 6.0, this would delay the Twenty Twenty-Two theme, hold back the launch of block themes in general, and delay a ton of user value in exploring ways to edit all parts of a site. You can see these thoughts reflected in some of my comments quoted in the following WP Tavern article: 

“We need to recognize the very Human situation we’re in right now both in terms of larger cultural moments coming up with various holidays/celebrations and the reality of still being in the midst of a pandemic,” McCarthy said. “Delaying provides sustainability to get this release right without potentially burning out the remaining contributor base.”

“FSE is a collection of features with some that are interconnected,” WordPress 5.9 Testing Co-Lead Anne McCarthy said. “This release includes a selection that are interconnected including Styles, Block theme flows, Navigation Block, etc. In order for them to really shine, it makes the most sense for them to be released together, making it hard to just delay shipping one. They need more time to be refined in order to be shipped together.”

Tied to this, I knew I wasn’t making a decision in isolation but within a wise, experienced, and diverse team, including folks who had been through multiple release cycles. This was first and foremost a group decision and one in which we each brought pieces to the table. 

What items need to be addressed?

I’ve seen rumblings around the overview list of 5.9 issues and how daunting it all feels. While the list looks long, these issues are achievable, and can be broken down into the following groupings: 

  • Design refinements.
  • Bug fixes.
  • Block theme considerations. 

Please keep in mind that only two issues were blockers for 5.9 beta (Add templates list page for site editor & Implement “Add New” for templates list in Site Editor) and both were addressed within around 48 hours of this list being compiled. Fifteen are blockers for the 5.9 release overall. Most of these will impact users using block themes (a subset of overall WordPress users), rather than all users of the software. Since the 5.9 release marks the widespread introduction of full site editing features, it’s crucial that the scaled down version shipping with 5.9 offers an excellent experience. 

For brevity, let’s review a few of these blocking issues to give a sense of the problems being addressed. This post can’t cover everything but if there are any issues in particular you’d like to know more about, comment below and I’ll update the post when I can with more context!

What’s the best way to move between templates, template parts, and styles?

To start, let’s talk about the biggest UX change on the list: the experience of navigating between templates, template parts, and Styles. This has been a longstanding issue with lots of history. By the time of the go/no go date, there were a few options to explore:

Depending on the implementation of each of these, the menu items under Appearance would adjust too! As you can see, this is a big decision that cascades to various areas of the experience. Here’s a quick video that runs through each in the same order as shared above:

Note that I had to use various versions of Gutenberg in order to replicate the different options, including rolling back to a previous version.

Initially, the middle ground option of providing a scaled-back browsing experience was deemed to have technical blockers and there was ample feedback around folks not enjoying the additional step to get back to the Dashboard. With extra time to explore a solution though, the middle ground option became viable and does a great job of offering a scaled back version of the original browsing option while not being overwhelming. Further, it quickly became clear that the tradeoff of adding an additional step to get back to the Dashboard was okay in light of the alternative being a much harder, convoluted experience to access Templates and Template Parts, key pieces of the full site editing feature set. 

Even though the decided pathway reuses the foundation of the original experience, it will definitely be included as an area to focus testing efforts for the FSE Outreach Program and for 5.9 in general!

Design refinements

The design refinements on the list are exactly that: ways to make the experience more intuitive and elegant, especially for newer features. For example, for blocks that have additional Typography controls, how can we make the tooling really shine? Outside of general interface updates, there are also tasks around things like making the placeholder option for the Post Featured Image block (a new theme block that displays your featured image) easier to manipulate while you’re building templates. Here’s a GIF from a recent PR that shows the update:

GIF showing how the featured image block can be manipulated visually when acting as a placeholder.

Another example can be seen in adding a fixed position to the add block appender to prevent layout shifts when trying to build with blocks, especially for nested blocks.

Bug fixes 

Alongside refinements, there are also obvious bugs to fix. For example, as you can see in the following video, there’s a bug in how the Styles are loaded when entering the Site Editor that’s already been fixed:

Block theme considerations 

Since 5.9 will mark the introduction of block themes, there are various issues listed to ensure those that explore this new era of themes have a great time building what they want, whether a theme author or end user. This includes everything from ensuring any Customizer links are properly redirected to iterating on the Global Styles end point to pave the way for aspects of block themes, like being able to bundle and switch between multiple Style variations.

I hope this post helped give you a glimpse into the thought and care that went into making this tough call. In all of the deep thinking and stress around decision making, it’s been such an honor to play a role on the release squad and to do so in a way where there’s room for me both to contribute and learn. I offer major props to the entire squad for coming together across timezones to dig in deeply, think quickly, and act wisely.

If this post sparks your curiosity, feel free to ping me with any questions (@annezazu on Make Slack) or reach out on my contact form! I’d love to help empower more folks to join the fun in the future, even when/especially when hard decisions are made. 

Keen to know what’s actually coming to the release? Check out the video below from yours truly to see a sneak peek:

By:

Anne McCarthy

Posted in:

, ,

52 responses to “Why I voted to delay WordPress 5.9”

  13. What I’d like to understand better is what are we going to do to make sure this doesn’t happen again? There could always be more polish, more bugs fixed, and I would challenge you to pick a year in the past decade that didn’t have its share of human issues. I’d like us to really understand and agree what went wrong, particularly in the first months of 5.9, and what we’re starting now to make sure 6.0 is effortlessly on time.

    Reply

    • Thanks for commenting and for your leadership, Matt! I’m keen to dig into these exact questions with the 5.9 retro and when the dust settles post 5.9. Sounds like a great follow up post idea. At a high level, I think a few things caused this: lack of contingency plans around the interrelated features, lack of clarity around scope for various individual features (particularly the browsing feature), lack of a comprehensive check in early enough ahead of feature freeze, and a need for more decision makers who have a high level view of where the work is headed. You can see each of these variables at play in issues like this: https://github.com/WordPress/gutenberg/issues/37075 Since this delay happened, more organization has quickly formed with more detailed overview issues, more conversation around scope for the release, and more regular testing by decision makers.

      Personally, I’d love to see the Go/No Go meeting overhauled to be less aspirational and more concrete as to where things stand as I think that’ll set the tone early enough in the release cycle to avoid some of these problems again. Here’s to never making the same mistake twice and carrying these lessons into the future!

      Reply

Leave a Reply to Anne McCarthy – Entrevista a una intermediadora de Automattic Cancel reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: