WordPress 6.5 Release Retrospective (Responses)

	A	B	C	D
1	What parts or processes of the WP 6.5 release worked well enough that you would keep them in 6.6 and beyond?	What would you like to add or see more of in future release processes?	What would you change, reduce, or remove from the 6.5 release experience or process?	What else would you like to express about the release process or squad?

2	24 hr freeze before release party	More lead dev or core committer feedback for feature projects	Make Gutenberg follow same rules as Trac for commit.	Need to have someone, preferably a lead dev, specifically identified for each feature project.
3	I'm not sure that there was anything new in this cycle that hasn't been done before.	Ownership and transparency of "leadership" decisions. Release Leads should be aware that they are essentially "shepherding" a release, not having any real power to add or remove a key feature. Continue the transparency for the retrospective raw data. Opinions about the takeaways from the data are purely subjective. Seeing the raw feedback adds more context for folks to come to their own conclusions.	For the last several major cycles, the project philosophies are brought up due to a feature not being ready in time for a set deadline. A few majors have now been delayed, and more and more, this just crams more features into a release. I would suggest either updating the project philosophies to allow for rare, extraordinary release delays, or commit to hard deadlines that free contributors to punt features that are not ready. This would increase confidence in the final release that's shipped. Schedule pressure may exist inside 5ftf companies contributing to Core, but that pressure (or the schedule itself)does not exist in the Core process. If a schedule exists, it should be known to Core, published, and owned by those creating it. Also, we're continuing to have walkthroughs/demos(whatever they are called) that end up negatively affecting the folks building the features being demoed. During the Fonts Library discussion, one committer mentioned "marketing" efforts that already noted the inclusion of the feature in 6.5. This should never preclude a revert of a feature if it's not ready. Also, the discussion leading to https://make.wordpress.org/core/2024/03/07/unblocking-wp6-5-font-library-and-synced-pattern-overrides/ blind-sided me as a co-Core Tech Lead. It seemed the relevant discussion happened in-person at WC Asia due to convenience more than anything. Sure, most of the folks are qualified, but this again speaks to the way some things happen in secret, despite efforts and calls for more transparency. Folks are less likely to buy into a decision if they are actively excluded from the decision making process.	It really seems like we're not bringing in and training up new contributors as most roles are not being filled with 5ftf sponsored contributors. It really feels like the release squad formation is not happening in the open like it used to be. The recent drop in Dev Chat attendance probably plays a factor, since open calls for volunteers user to happen much more during these meetings. I don't think one post at the beginning of the year asking folks to raise their hand for any one of three majors in the next 12 months is the answer. Folks availability changes throughout the year. Instead, we should go back to more openness in the formation, more frequent, widespread calls for volunteers, and offering new folks a path to joining a squad instead of calling them "cohorts". Lack of interest may also be due to the perceived lack of appreciation and celebration of leads. It seems that recent leads feel like they're just filling a role versus achieving something special with agency and reward. I'm not sure it's compelling for folks to join a squad when all they get is their profile picture on the about page that almost no one sees anymore. Perhaps, instead of centering all the marketing of a major around a jazzer that few might be interested in, let's tell the stories of the folks leading the release. Make them feel appreciated and special again. I completely understand that having a singular "thing" to help market a release is easier than using a squad of 10-15 people. However, just because it's hard doesn't mean we should avoid it. Maybe start with a callout in the SotW? Matt seems to focus on the current release, but really, he should go over all the releases for that year and thank each lead.
4	General release script is little simplified. It could be useful for future release teams.	In the Beta/RC release post / in the Dev chat summary / any separate post, we could list out points to contribute per department. It will help contributors focus their efforts in those areas. This will also make it simple for new contributors. For example, For #core -- Following is the list of tickets/boards to contribute to the current release. For #Polyglots -- Request contributors to view https://translate.wordpress.org/projects/wp/dev/ & contribute to your desired language. Let's strive to make it 100% For #Documentation -- Kindly contribute to these tickets. etc.	For Major features like Font Library assign owners & add one or more backups depending upon feature size. It will make it easier to ship the feature. In case of any blocker to punt the feature.	The current 6.5 release squad team size per role is good enough. We had enough backup. It helps if anyone is unavailable, another person can take over. As the release progresses there could be a scenario of urgent Beta/RC cycle, in such cases having backups is helpful.
5	- The number of Beta & Release Candidates and their cadence. - The actual release parties	I would love to see the docs leads collaborate more with the design team for their work on the Field Guide etc. Personally, I find there is a lot we can learn in Core from the way Gutenberg does its release posts. They are much more readable/clear because they include graphics/videos. Especially this time around I feel like the dev notes & field guide felt very disjointed/unorganized. There wasn't really a clear lineage through them. Some information was duplicated, other info was not called out clearly enough. And I feel like the focus was not really placed on the main things in this release. Besides this, I was also very surprised that the first time I heard about being a part of the release squad was when the official announcement post was released. Yes, we all volunteered for the roles. But I still would have loved to get a quick heads-up/confirmation before the post was published. It felt very unpersonal this way. I would also love to see more clear communication happening within the release team. As someone that was part of a release squad for the first time I still felt like I was very much on the outside. Like I didn't actually have any meaningful say/was empowered to change/decide anything. The way it felt was that there is this established group around Mattias (Saxon, Rich, Anne, Hector) that sets the Roadmap (https://make.wordpress.org/core/2023/12/07/roadmap-to-6-5/) long before a release team is formed. I would love to see release teams get formed before the prior release is completed so that the team can hit the ground running and can help shape the roadmap with what they currently see as areas of focus in the community. I would also love to somehow get a better overview of the current focus areas of the various core contributors who spend the majority of their time every week working on WordPress are. Maybe that happens through the core chats, or some other way. That coordination is clearly happening somewhere. But it is almost impossible to see/figure out as a release lead. So it is hard to know whom to reach out for to get questions about the status of a feature answered for example. And finally I'd love to see us improve how we handle merges from Gutenberg features into Core. The way it works today is that essentially everything that is in Gutenberg at the time Beta 1 comes around just gets merged over. (Unless we specifically do work to exclude something). This means that we don't really evaluate the readiness of any individual feature. I would love us to come up with better ways to determine what the MVP of a feature before it gets merged into Core is and then have systems in place (whether its feature flags or whatever) to make that process easier. I want us to be able to experiment and merge quickly in Gutenberg. So that we can get feedback and have these quick iteration cycles. But currently, that means more often than not we release half-baked features just because they were in active development in the Gutenberg plugin.	I would love to get clarification on the "Release Lead" role. I think it might be time for a change of how that role works. It feels like Matt has that role so that he can veto anything / make the final call. Which I am perfectly happy with by the way. But maybe we should just acknowledge / document that right and then let someone that is currently actually leaned in and able to provide a clear vision / structure to a release team. The way it works right now it really feels like we are a dispersed group of various teams that don't really have a visible leader and therefore are all operating in our own little silos.	Besides all the flaws & challenges I called out above I still found it a great honor to have been part of this release and am looking forward to hopefully many more similar opportunities. I'm only this critical because I care deeply about this project and the community around it :) Also since I called them out earlier, I love Mattias, Saxon, Rich, Anne, Hector and appreciate all the work they do. This community is better because of them and I am grateful for what they do :) All I hoped to say with that section is that I feel it is currently a little opaque from "the outside" how / where some of these decisions get made. Even as a part of the release team.
6	As a contributor, I found it helpful that there were more than one Editor tech lead because it meant that they had a higher availability to answer questions. ------ As the "default themes lead", or rather "theme wrangler", I believe part of my responsibility was to evaluate wether the theme wrangler / default themes lead should be part of the release squad. It would have been helpful to have someone to discuss this with. TLDR: I think it is important to keep the bundled themes up to date. It is beneficial for the person who is working on the bundled themes to stay informed about the active discussions about a release. Especially because there are always late changes that affect themes where pull requests may need to be created quickly, or even reverted. - But, I’m not sure if or in what way the role is beneficial for the squad. - I was not sure how to best help the rest of the squad. - I was not sure what help I could expect from the rest of the squad. - I think that wether this role should be part of the squad or not, should depend on if there are major changes planned for themes. https://make.wordpress.org/core/handbook/about/release-cycle/wordpress-release-team-and-focus-leads/#default-theme-wrangler	Better planning and more transparency when proposing and introducing new features. This release has showed that larger features benefit from being treated more as "feature projects". With proposals for inclusion and descriptions of architectural decisions being published early, so that changes may happen early and not be blocking. https://make.wordpress.org/core/features/ Even though the fonts api is listed on this page, change requests happened so late in the process that it delayed the release.	Like I wrote above, I am not sure if or how the default themes lead is helpful to the squad.	In my role as the "default themes lead", or rather "theme wrangler", I felt lonely. I did not find help within the release squad to: - Define the role and tasks - Discuss specifics like wether or not new features should be enabled in the bundled themes - Identify theme related changes I did not know who to reach out to outside the squad eIther. I understand that it was part of my task to figure these 3 things out, but it is difficult to work alone all the time because then I am limited to my own perspective. I found the documentation of the release process lacking regarding the themes. There is no information about when the changes to the theme readme files need to be committed, or who publishes the theme change logs: the theme contributors or the documentation team? It felt like I was assumed to already know many things. And I am an experienced full time contributor, I think that someone who is new to being in a release squad would have had a more difficult time. ## Difficulties with implementing new features in the same release as they are introduced One of the responsibilities for the theme wrangler is implementing features that are added in the current release. In reality, the bundled themes will always be at least one release behind, and likely several releases behind. There is not enough information about theme changes early on, and not enough time for implementation and testing before the feature freeze and code freeze. I think it’s important for one or more people to dedicate time and effort to ensure that the bundled themes are compatible with new editor features. This means that they need to be informed of changes that affect themes. And I think we as contributors can do much better here. - It can be difficult to learn about editor changes early enough to take action: - If a change that effects themes is not announced until a Dev note is published, it is too late for the people working on the themes to implement changes. - This could be improved with better communication and better labelling of editor issues in the Gutenberg GitHub repository. - Changes are merged into core late in the beta releases: - If a change that effects themes is merged late, it can also be too late for the people working on the themes to implement changes. - This could be improved by merging changes earlier. - If a change affects classic themes, then it must also be tested with a classic theme before it is merged into Gutenberg and core. Often, bugs are found late because classic themes are not considered when new features are planned.
7	Image shadows	Being able to do basic typography, like using different font size and fonts in the same paragraph.	No idea.
8	Most of the process was smooth. I appreciated the help from the triage folks, the release channel on Slack.	Nothing comes to mind.	The release ceremonies for betas, rcs and stable are too long and generally useless. Most of the work can be done in a command. A committer or tester should only be needed if a problem occurs. It would reduce the potential of errors (like what happened for 6.5.1). Define who makes the architectural decisions more precisely to avoid what happened on the Font Library and avoid being reactive to vocal people. There are vocal people sharing conflicting opinions and the decisions should not come down to who has the loudest voice.	We should have a "release team" but not a squad of release leads. One or two release leads should be enough and the release leads should be able to rely on their team to split the work.
9	1. Having releases run by squads rather than individual leads continues to work well, though the number of co-leads for each area could be reduced. 2. Minor releases during this cycle were better organized than previous releases. Having volunteers ready to lead these releases made a huge difference.	1. We need to sync GB packages much earlier and more often during a release cycle. Major changes to the software are not visible until after the first sync, which happened right before Beta 1 (this commit: https://github.com/WordPress/wordpress-develop/commit/cf8b74de164f322a78ea51921b236213805e6f79). Having such a big change land at one time makes it very hard to diagnose the cause of a bug or performance regression. 2. I would still like to see us increase our release cadence for major releases significantly. We should be able to punt a feature like Font Library without needing to wait months for a new release to go out. Being able to promote and release major features from alpha/beta/major within 6–9 weeks would be much better.	1. The release squad was named very late, on Jan 18, less than a month from the first Beta (Feb 13). At minimum, release leads for product, engineering, and coordination need to be named at the start of the release cycle. Additionally, as one of the release focus leads, I found out that I was named to this role when the post was published based on the fact that I had indicated a willingness to serve at some point during the year. Getting confirmation would have been preferred. 2. We continue to have named release leads who are not actively executing the role, which leads to confusion about how and who can make key decisions about a release (e.g., the Font Library). Release leads need to be the final arbiter of what gets included or punted from a release, or we need to clearly delegate that responsibility to other roles. 3. I am VERY appreciative of the "Source of Truth" posts each release, and thought that collaboration on that post was great. However, the fact that it's published on Anne's personal site, and not on an official communication channel of the project feels like a miss to me. I'd strongly suggest that we build on the great communication work Anne has been doing to publish this as an official post on one of our project sites. Otherwise, we're fracturing our efforts and duplicating the same/similar info for our news, dev, and make/core channels. 4. We need to be better at sticking to feature deadlines for releases. The Font Library was not ready for merge in time for Beta window, but was allowed to continue to be part of the release. Then, major issues were raised at the RC date, at which point, we should have punted the feature. The fact that we didn't hold ourselves to our own process standards for this feature created a lot of stress on the release during the final weeks.
10	Most of it. However seems there were a lot of release leads and seems some of them were more like "release helpers". Perhaps may be good to revisit this again and split it in two? - Release leads are the people whose decisions affect the release. - Release "coordinators" would be the people who work on different tasks like write the beta, RC, release posts, set up and lead bug scrubs, etc.	Perhaps a way to get (most of) the committers to review the changes that are coming from Gutenberg earlier, at least before beta.	Perhaps some guidelines on the criteria for postponing a WP release. 6.5 was delayed by a week for seemingly a very minor benefit to a very small group of WP users (less than 0.1% of the users?).
11				I’ve been contributing to WordPress regularly for [several] years (since WordPress 4.1) and have never felt as burnt out following a release as I did/do after WordPress 6.5. This includes [a release] in which I was the sole tech lead. Another contributor pinged me in Slack on the day of Beta 1 asking me to assist on the Font Library, which I was happy to do, and I found it one of the most frustrating experiences in my history of contributing. There was a complete breakdown in processes as half a dozen contributors with more than a decade’s experience developing Core were dismissed on the basis that the location of font files was an architectural/philosophical decision. Requests for links to this decision went unanswered. Once the compromise approach was decided an issue to discuss the architectural approach got minimal buy-in from team members who had been working on the feature. By the time it came time to reconsider the fallback approach (a good and healthy approach — as it adapts to learnings) I didn’t feel comfortable raising my preferred option as I experience suggests it would lead to a circular discussion and again be dismissed as an architectural/philosophical decision. As I’ve already raised in the release and editor slack channels, I think the Font Library feature highlights the need for the following: more frequent editor package syncing to the WordPress-Develop repo — this has been a long term wish list item from regular contributors to both the Gutenberg and wp-dev repos in an effort to reduce the workload and stress of merging in the lead up to the first WP beta. Regular posts on make/core highlighting important discussions taking place on the Gutenberg repository that would benefit from input from a wider group of contributors in an effort to encourage further cross contributing to repositories.
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100