Early Thoughts on WP5.8 Planning

Now that WordPress 5.7 has been successfully launched, we’re all turning our attention toward WordPress 5.8. I’ve pulled together some initial thoughts about how we can do some contingency planning as we work toward our April go/no go dates for full site editing so that we’re prepared for either outcome (go or no go).

Right now we’re still in the iteration phase for WordPress 5.7 where we look to quickly reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to issues from 5.7 in 5.7.x minor releases, but trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. is open for WordPress 5.8 contributions and the 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/ 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 work is going at full speed. To help us keep our momentum and avoid burning people out, I would like to try the following:

1. We assemble a skeleton crew of Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and Coordinator who can help us catch bugs for WP5.7.x minor releases, and group tickets into future milestones.
2. “Go” scenario: If we reach our April dates with a promising prototype in the plugin, then we merge it to trunk, and assemble the rest of the release squad with a focus on full site editing in WP5.8 in July.
   “No go” scenario: If we don’t have a promising prototype, then do not merge it to trunk, and assemble the squad with a focus on essential updates to ensure we’re ready to merge prior to WP5.9 in December.
3. For the release that includes full site editing, I would like to pause our cohort mentorship processes and replace it with a public coordination channel for the release squad that allows passive learning through observation and release squad transparency. This will allow the release squad to focus fully on the merge of full site editing while not completely halting the ability for others to observe and learn.

I know we have a collective need for some clarity at this point in the process, which I’ve shared with a little depth on Updates. I do want to remind us all to balance our desire for predictability with the knowledge that being a little flexible can result in a better experience for the many users who rely on us.