WordPress 5.3 Retrospective Recap and Next Steps

The week of WP 5.3 release I posted a call for feedback for the development workflow.

Thank you to everyone that left their comments! Reflecting on what worked and what didn’t is a great way to move forward together and steer the wheel if and when needed.

Some comments didn’t follow the proposed format of start/stop/continue so it wasn’t very clear where they fit: I tried to put them in one of the categories. I also rephrased some feedback that was sometimes given as a positive statement (continue doing A instead of B) and sometimes a negative statement (stop doing B and do A). Finally, I added feedback I collected from the focus leads or from anonymous sources.

If something doesn’t feel right let me know and I will amend the post.

Read on for everyone’s feedback!

The questions

  • 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?

Recap of the feedback

Start

  • Adopt an opt-in methodology as opposed to an opt-out that might require some tech-savviness.
  • Clarify how new features are accepted.
  • Release when bugs are patched and tested, especially bugs that involve errors printed on the page (PHP Warnings).
  • Give more attention to fixing bugs reported instead of adding new features.
  • Give more time to plugin and theme authors to adjust to changes introduced in the new version of WordPress.
  • Publish Field Guide during Release Candidate 1 (at the latest) without further changes.
  • Introduce a “doc-updating” stage in the release to ensure that documentation is up to date.
  • Introduce a more formal procedure to communicate what has changed between releases of Gutenberg.
  • Release more often, since there is a big gap between the Gutenberg releases and the major version of WordPress.
  • Move back to a more predictable release schedule and announce it as early as possible.
  • Ensure each major feature/focus in the scope of the release has someone doing a weekly report. Actively checking on this.
  • Plan ahead for the next release cycle during the current one.
  • Write a description of the release squad roles.
  • Add one more focus lead for Documentation.
  • Add a Core Design focus lead.
  • Find a more inclusive way to nominate and select focus leads.
  • Mentor each release.
  • Encourage testing, since it is pivotal, and recognize the effort.
  • Review how we do the credits list.
  • Communicate “What’s New” with a modal dialog.
  • Check component maintainers’ availability and publish it to facilitate cross components and teams collaboration on features.
  • Publish a weekly agenda ahead of time (24 hours at least) with a list of topics.
  • Hold early-commit scrubs where maintainers and the broader community can weigh in on tickets that have patches ready.
  • Timely communication to plugin and theme authors about upcoming releases (Even a generic “Heads up this is coming”, so if it somehow affects their product they will be more eager to pay attention).

Stop

  • Ignore patches that have been ready for years. They cause demotivation amongst contributors.
  • Release based on a time range/fixed number of releases and not when features are ready.
  • Introduction of changes late in the cycle: it doesn’t leave enough time for plugin and theme authors to test and release.
  • Use role names that don’t reflect the activity during the release cycle.
  • Work on the About page until the last moment.
  • Develop new features in silos.
  • Set release objectives that involve multiple teams, components, and individuals without first discussing the priorities with all parties involved.
  • List only “Core Developer” as a role on the props page.
  • Have a release focus leads private channel.
  • Update external libraries close to Beta time.
  • Introduce new technologies without a prior, broader discussion.

Continue

  • Have a dedicated person to facilitate meetings and keeping track of milestones.
  • Propose schedule, scope, and focus leads at the beginning of the release cycle and publish all the milestones.
  • Communication across teams and give timely feedback.
  • Iterate on the About page process and improve it together.
  • Have a team of focus leads.
  • Publish the list of bugs that will be tackled during bug scrubs in advance.

Next steps

Although all the points are very valid, some can not be addressed at this time.

I will focus on the ones that could be implemented starting from 5.4 or have an ongoing conversation attached

The others are not lost! This is why I asked for your feedback and they are documented here. My understanding is that we deal with a limited amount of resources so prioritizing is key.

Improvements and iterations for 5.4

These are the low hanging fruits, let’s do them!

Release Team, Component Maintainers, Core Committers

  • Continue with the release squad model.
  • Mentorship model: focus leads of 5.3 help 5.4 and so on.
  • Write a description for each role involved.
  • Make an open call for volunteers. Team reps and previous release leads can nominate people that:
    • Are willing to take part in this.
    • Are a good fit.
  • Add a Design Focus Lead.
  • Add another Documentation Focus Lead to ensure a timely publication of Dev Notes and Field Guide and facilitate the addition of a “docs-updating” stage.
  • Add a Test Focus Lead.
  • A private channel for the release team. It provides the new focus leads a safe space to learn and ask questions that they might feel intimidated by asking in the Core channel. No decisions are made in the channel.
  • Add some tasks to the release coordinator role:
    • Ping component maintainers and core committers at the beginning of the cycle and every few months to ensure there is a clear picture of availability
    • Ping active component maintainers weekly to give a status report. This could be done in two steps: automated post on the Core blog followed by ad hoc pinging in case of no reply.
    • Office Hours to facilitate cross-team collaboration.
  • Rethink roles of the release to give better credit. Define roles (are they even needed beyond the squad?) and be generous with props.
  • Publish the agenda for the dev chats 24 hours prior to the chat with a more structured model.

Procedures

  • Call for tickets and component focuses
  • Recap of the above with reasoning behind the decisions taken regarding the features that will be considered
  • Propose schedule, scope, and focus leads at the beginning of the release cycle and publish all the milestones.
  • Continue using a sticky post to announce bug scrubs and publish in advance the list of bugs that will be tackled.
  • Actively communicate throughout the release cycle with plugin and themes authors (How? To be determined with the respective team reps).
  • Hold early-commit scrubs (daily? To be discussed) in the first week of the cycle.
  • Milestones – Hard Rules, not guidelines 😉
    • Beta 1
      • Soft string freeze
      • From B1 onwards, only bug fixes and blessed tasks
      • All Dev Notes published, even with a “not final” disclaimer
      • About page draft based on Dev Notes
      • About page design mockups
    • Pre Release Candidate 1
      • Field Guide published before RC1 or on the same day at the latest
      • About page content finalized
    • Release Candidate 1
      • Hard string freeze
      • About Page design finalized
    • Release Candidate 2
      • Bugs after RC1
      • Regressions
  • Avoid
    • Updating external libraries close to Beta time.
    • Introducing new technologies without a prior, broader discussion.
    • If the above mentioned are absolutely necessary for the release, they have to be brought up in a timely manner to leave enough time for discussion.

Documentation

During the release cycle, it became clear that some of the documentation about the release processed is outdated or not fully clear.

I took quite a few notes and I know @azaozz and @jeffpaul did as well. I will work on this during the 5.4 release, with additional input from the next squad.

The goal is to have a complete revision and update of this by the end of 5.4.

Proposal

I will create a collaborative Trello board where we can (try) to keep track of all the moving parts without having to be in all the different channels. This should also help us keep track of deadlines in a more effective way than a post on the blog that we need to look up every time we need to remind or remember the dates. 😉

It’s an experiment. If it fails, we ditch it.

Marketing – Ongoing

How do we let the world know about the awesome features that are coming up if they don’t follow the Core blog?

To be determined by the Marketing Team.

Release cadence – Ongoing

There are a few interconnected, lively conversations in the comments of these posts:

  1. The original post about Major and Minor Version Release Cadence – February 27, 2019
  2. Recap of Devchat after the hour: November 20 – November 20, 2019
  3. Tentative Release Calendar 2020-2021 – November 21, 2019

The reason why we can not switch to more frequent releases is not in the lack of willing, there seem to be quite a consensus about speeding up, but the lack of automated procedures of deployment.

Proposal

Create a working group that will asses the situation, take stock of all the existing procedures, tooling needed, etc… After a thorough review, the working group can present their findings and we can use a responsibility assignment matrix to come to a conclusion.

(Lost) Trac – Ongoing

What to do with old bugs that might or might not have patches that might or might not need a refresh?

To be determined by the Triage team. The addition of early-commit scrubs could help?

You made it to the end of the post! Thanks for your attention, now let’s go make WordPress!

#5-3 #retrospective #summary