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).
- We assemble a skeleton crew of Triage 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.
- “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.
- 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.