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 (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 Warnings).
  • Give more attention to fixing bugs reported instead of adding new features.
  • Give more time to pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme authors to adjust to changes introduced in the new version of WordPress.
  • Publish Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. during Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 Notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. 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:
    • PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” 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 blogblog (versus network, site) 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 TrelloTrello Project management system using the concepts of boards and cards to organize tasks in a sane way. This is what the make.wordpress.com/marketing team uses for example: https://trello.com/b/8UGHVBu8/wp-marketing. 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) TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. – 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 Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. 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