Héctor Prieto 11:15 am on May 27, 2022
Tags: 6.0 ( 76 ), retrospective ( 20 )

WordPress 6.0 ‘Arturo’ Retrospective

With WordPress 6.0 out in the world, it would be very helpful to this and future release squads if all those involved in contributing could take some time to reflect and share our thoughts on the release process to learn, iterate, and make future releases smoother. ✨

Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. The survey is not anonymous if I need to reach out for further clarification, but your email address will not be shared or used for any other purpose.

To accommodate for WCEU2022 taking plac e next week, the form and comments will be open until June 19, 2022. The results will be reviewed and summarized in a follow-up post in this same blogblog (versus network, site) in late June 2022.

Thank you, everyone, for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!

Props to @annezazu for peer review

#6-0 #retrospective

zieladam 3:27 pm on June 14, 2022
Me and @gziolo were both Tech Editor Leads. I filled the Google form and also wanted to share my answers publicly:
What would you keep about the WP 6.0 release experience or process?
- Getting to know the community
- Friendly, supportive atmosphere
- Lack of heroic efforts and last-minute dashes
- Collaborative decision making, e.g. with regard to the WebFonts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
- I loved that everyone answered my pings timely and in a friendly way. Everyone was reliable and keen to help – the release came out great thanks to you all!
What would you add to the 6.0 release experience or process?

Automations – my time allocation as Tech Editor Lead was ~30% watching over things, deciding, communicating and ~70% mundane, repetitive work (typing the same commands some hours each week). I’d like it to reverse these proportions.

Me and @gziolo automated:
- Cherry-picking PRs in 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/ repo
- Publishing Gutenberg packages
- Updating WordPress packages in the wordpress-develop repository
- Synchronizing the stable blocks from the Gutenberg repo to wordpress-develop repo
We’re going to provide more details and examples in an upcoming post/issue and discuss what would the next steps there look like.
What would you remove from the 6.0 release experience or process?

I have two points, both are being discussed on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ – if you have an opinion, you’re more than welcome to join the discussion!
- Backporting PHP changes. Combing through months of Gutenberg Pull Requests to find the ones to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. into the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. release is tedious detective work and it’s hard to make an error. It is painful for the release leads, for the PR authors, and for the reviewers. In my ideal scenario, we’d backport changes as we go and avoid this big effort largely or entirely.
- __experimental APIs audit. It happens on every release, but the number of __experimental APIs never goes down. We need to find a different way of introducing, stabilizing, and phasing them out.
- zieladam 3:41 pm on June 17, 2022
  
  Oh, one more thing to add:
  
  Me and @gziolo co-lead the release of the final 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/ version included in the WordPress 6.0 and I also conducted the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor chat on the same week. Both have been hugely helpful for the purposes of releasing WordPress 6.0.
Birgit Pauli-Haack 1:31 pm on June 16, 2022
Until I became part of the release squad as a rookie, many aspects that go into a release have been a mystery. Most still are. I learned a lot from the contributors on the WordPress 6.0 release team. The more I know, the more I know what I don’t know.
It has been a great pleasure and honor to work with all of you on this release, and I hope to be part of a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. in the future. What’s the saying? “Practice make perfect.” 😊

I am awed by all the brilliant people who make WordPress and the releases run smoothly.

Thanks everyone on the team, for your patience, advice, and help. Big Thank You to @milana_cap 😍 who did the major lifting for the FieldguideField 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. and her vision on process and execution, to @webcommsat 😍 for the invisible work of reviewing the posts and facilitating cross-team communication and to @jeffpaul 😍 for great advice and support on outreach tasks.

Here are my answers for the retrospective:

What would you keep about the WP 6.0 release experience or process?
- Awesome collaboration. Everyone was really helpful and answered my rookie questions and provided great advice.
- Release channel for coordination / Weekly check-ins worked well
- Great team on Documentation with Milana, and Abha.
- Thank you to all maintainers and developers. They answered questions regarding 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. and DevNotesdev 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, and 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. promptly.
- Keep process 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/ changelog to triage document for user-facing documentation.
What would you add to the 6.0 release experience or process?
- Start early labeling PRs and commits of the milestone with “Needs Dev Notedev 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, and 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.”.
- Create an automation process to collect all “Needs Dev Note” PRs and commits into a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Project from both, tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and GitHub.
- Add flags for the three docs types: DevNotedev 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, and 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. / MiscDevNote / Field guide
  This way, we can decide early, what goes into a single DevNote post, what will be handled in a Misc Devnote post and what goes into the “Wait there is more” section of the Field Guide (Links to 6.0 Examples)
- Brainstorm with developers and other documentarians how to best provide the draft DevNotes for review and publishing. The process for 5.9 and 6.0 for GitHub didn’t work well.
  Idea: Add DevNotes to the particular PR in the comments section. If a Dev note covers multiple PRs, select one and mention the other PRs. Github will provide reverse linking. Would that also work for Trac?
- Create process documentation for the call to Maintainers for the Field Guide blurbs for issues that are worth noting but don’t need DevNote treatment.
- For Gutenberg developers, start now with DevNotes of features that already landed and add them to the PR as comment.
- Add documentation lead role for End User documentation
What would you remove from the 6.0 release experience or process?
- Stop using comments on the GitHub DevNote tracking issue for collecting all GB DevNotes. The problem is: no threads to comments. Every comment will land on the bottom of the issue, and not next to the DevNote for reviewers.
- Move the deadline for DevNotes 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. 1, so the docs team can give all DevNotes proper consideration and review. Last-minute push of features into the release during Beta cycle, can be dealt with, better even when the rest of the DevNotes are already out of the way.
Milana Cap 8:15 pm on June 19, 2022

Thank you @bph for kind words. It’s been pleasure to work with 6.0 squad.

I’ve already submitted my feedback but I’ll add here a couple of things.

I would completely remove the process for writing 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, and 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. in 6.0. We made a huge circle that only complicated things. All devs who are writing dev notes are going to be post authors for that dev notedev 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, and 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. (except maybe for mixed dev note) so I’d rather have their draft in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blogblog (versus network, site) directly. Yes, we can’t comment in blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor but to be honest we really shouldn’t. I’ve been working on docs for past 3 releases and there was only 1 time when I needed additional clarification from the author. This can be handled in slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. DMs or in any other way that works the best for everyone involved. There is no need to have dev notes posted in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ comments, copy/pasted in Google docs and then copy/pasted in core blog. That triples the amount of work during the busiest week of release for docs team.

In a long run, I think it would be beneficial to everyone if we, from the beginning, assigned one documentarian to each ticketticket Created for both bug reports and feature development on the bug tracker. that would need docs, any kind of it. This documentarian can follow the process, ask questions, prepare code examples (if they are also dev) and basically document everything before the freeze phase. And then there’s 3 weeks for all of that to be wrapped in nice words. This could help devs to learn how to write docs (because a lot of them don’t know how to do it which often leads them to procrastinate writing dev notes), release would have a very detailed docs and documentarian could learn the process of contributing with code and maybe try that in the future release.
- Milana Cap 8:19 pm on June 19, 2022
  
  I’m not sure what’s happening with this comment above. As soon as I submit it, it gets edited and when I try to edit it added content disappears.
  - Sergey Biryukov 8:50 pm on July 13, 2022
    
    It looks like there is an issue with glossary tooltips, which can break markup in unexpected ways, adding extra text to the comment. I have reopened the related MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.: #meta4507.

Comments are closed.

Welcome!

Communication

WordPress 6.0 ‘Arturo’ Retrospective

Welcome!

Communication

Share this: