Aaron Jorbin 4:56 pm on August 31, 2023

Proposal: An update to the Field Guide

This proposal comes out of an ad-hoc session at the WordPress Community Summit. This session grew out of discussions during the session on backward compatibility in 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/ where it was noticed that some WordPress changes are easily missed by the extendors of WordPress and WordPress site builders.

Background

The Field Guides in WordPress started in 3.4 and have been consistently published since WordPress 4.1. In this time, they have grown in length due to an increase in both the number 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, 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. and the number of changes in each version.

Longer posts can be more difficult to read to completion and this can cause important information to be missed. Additionally, as much of the information is linked to rather than included in the post it takes effort to truly understand the breadth of changes in a WordPress release. All of the information that is published is valuable to the WordPress community, so discouraging the publishing of content would be antithetical to the goal of informing and helping the WordPress community and is not something that is desired.

Proposal

The first part of this proposal is to continue publishing the existing 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. on this site (make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.) but adjust the target for publishing it to the final scheduled 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.. Currently, the target is to publish the Field Guide at the same time as RC1. This doesn’t change the amount of work for the release team, but it does move the target up by approximately one week. Publishing this earlier will give some additional time to update documentation, encourage testing from the community, and also allow for time to prepare for part two of this proposal.

The second part is to start publishing a simplified Field Guide to the WordPress Developer Blog. The audience for this guide is primarily two groups: Extenders of WordPress such as 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 and Developers building custom sites. This simplified guide will focus on the following things:

Large features that developers would want to tie into
Changes with a high potential of causing breakage
Features the core team wants developers to start using right away as the use of them will benefit WordPress end users.

As an example, a hyper-focused Field Guide for WordPress 6.3 could have highlighted the new command palate (a large feature that developers would want to tie into), Async/Defer in the script loader (a new feature that when developers start using, WordPress end users will benefit), and the post editor being iframed (a change with a higher potential of causing breakage).

The target length of this Field Guide should be 800-1000 words and it should link to but not embed any other documentation such as dev notes. The target will be to publish this post within one week of RC1. The same process for all content published on the developer blogblog (versus network, site) will be followed and the release documentation lead(s) or their designee will be expected to work with the WordPress Developer Blog team in the #core-dev-blog channel and the developer blog content GitHub repository to coordinate the content and publish date.

Provide feedback by 15 September 2023

This proposal is one step, but not necessarily the only step, at improving communication around WordPress releases and making it easier for WordPress updates to instill confidence. Feedback will be accepted until 15 September 2023

Thanks to @annezazu, @webcommsat, @ndiego, and @jeffpaul for feedback on this proposal prior to publication.

Jeffrey Paul 3:12 pm on September 1, 2023

I’m in favor of this proposal and would add that perhaps we consider what these two “guides” are called to make it as clear as possible what the intent/audience is. Perhaps “Extenders Guide” and “Technical Guide” or some iteration on those?

Tagging the WordPress 6.4 release leadRelease Lead The community member ultimately responsible for the Release., release coordinators, and documentation leads to consider testing out this change during the current 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.: @chanthaboune, @cbringmann, @metalandcoffee, @francina, @webcommsat, @femkreations, @611shabnam.
- Aaron Jorbin 6:41 pm on September 1, 2023
  
  Thanks! I like the idea of a name specific to this new guide. Perhaps “Technical Highlights of WordPress X.Y” to identify that it is not a comprehensive guide?
  
  Also tagging @greenshady and @bph as two of the leaders of the developer blogblog (versus network, site) who may have a better idea for a name (and opinions in general on the proposal)
- Justin Tadlock 8:06 pm on September 1, 2023
  
  I’d lean toward using “Extenders” in the title.
  - Aaron Jorbin 5:32 pm on September 12, 2023
    
    What do you think of “Extenders Guide of WordPress x.y”?
    - Justin Tadlock 5:32 pm on September 14, 2023
      
      That’d work. Or, “Extenders guide to WordPress x.y”?
Justin Tadlock 8:03 pm on September 1, 2023

Proposals for the Developer Blogblog (versus network, site) should be opened as a Discussion on the Dev Blog Repo too. The team votes on and/or discusses proposed topics during the meeting on the first Thursday of the month (September 7 will be the next one). It’d probably be a good idea to go ahead and open that discussion there (or before the October meeting), even if it’s just to link to this post. This will make sure this is going through the normal process.

Now onto the proposal:

Do we need a simplified 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. on the Dev Blog?

One thing that we already put together is the What’s new for developers? post every month on the 10th. This focuses very specifically on features/changes/bugs/etc. that 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 should know about. I feel like it sort of already serves the purpose of the proposal here.

For example, each of the 6.3 features pointed out in the post (command palette, async/defer, and editor iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.) were all mentioned in these monthly posts.

I think what’s really missing is readership at the Dev Blog. While the monthly posts are among the most read there, we’re still not reaching enough of the wider developer audience, at least not yet.

I suppose what I’d want to figure out would be: how would this differ from the monthly What’s new for devs? posts?

Other areas of improvement:

This might be a bit of an alternative, or at least, a complementary proposal.

We are short on practical guides and tutorials on new features/changes coming in the next WordPress release. I believe more of this would go farther in helping developers get up to speed with the next release.

For example, there’s an open topic on the Command Palette API. Ideally, that would’ve been proposed as a topic as far back as July and written by the time WordPress 6.3 was out.

The few authors who currently contribute do cover some of the upcoming features in depth, but we could use more contributors tackling these topics. Right now, it’s mostly a matter of not having enough people to do it.
- Jonathon Leathers 10:18 pm on September 1, 2023
  
  I just want to underline the point about readership of the Developer blogblog (versus network, site). I had no idea that even existed, which is a shame, because there is great stuff on there.
  
  I know it doesn’t help with whether a new post needs to be made in addition to the monthly posts, but there is definitely an opportunity to make the developer blog more prominent.
- Aaron Jorbin 5:51 pm on September 12, 2023
  
  Proposals for the Developer Blogblog (versus network, site) should be opened as a Discussion on the Dev Blog Repo too.
  
  Done. https://github.com/WordPress/developer-blog-content/discussions/169
  
  RE The overlap with “What’s new for developers?” While I think those are great posts, I think they serve two different purposes. This new post is aimed at answering the singular question “What is the key information that extenders need to know to be ready for WordPress X.Y” rather than “What changes are happening and being discussed” which the “What’s New” posts answer.
  
  Additionally, the “What’s new” posts are long and substantial posts similar to the Field Guides. The September post has 26 subsections.
  I think what’s really missing is readership at the Dev Blog
  
  Hopefully a single post about each release that can be promoted wide will help extenders discover and become regular readers of the dev blog.
  We are short on practical guides and tutorials on new features/changes coming in the next WordPress release.
  
  I agree that this would be a great compliment to help the extenders of WordPress.
  - Justin Tadlock 5:49 pm on September 14, 2023
    
    Thanks for the reply. This helps clarify things. I could definitely see that working and adding a lot of value. I’m sure folks have plenty of thoughts on the benefits/value of it, but I don’t think we can really know until we give it a shot.
    
    There’s just one remaining hurdle that needs clearing for me:
    
    The Dev Blogblog (versus network, site) part of this proposal was briefly discussed in the monthly meeting.
    
    But I’ll add here what I said in the meeting, or at least further clarify: one of the easiest ways to get things on the Dev Blog is to have a person take ownership of a particular post/project. If someone says, “I’ll wrangle these resources and write the post for WordPress 6.x,” it’d be an easier onramp to getting something on the Dev Blog.
    
    Making sure these go live for each 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. is a big commitment. And the general sentiment, at least as it seems to me, is that the Release Squad is already spread pretty thin.
Milana Cap 11:04 am on September 4, 2023

If the “Technical guide” is going to be moved one week earlier, then a lot of other things should be changed in the release cycle as well.

First and foremost, 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. must be drafted much earlier in the cycle. Developers must communicate with documentarians more often and from the beginning of the release cycle.

I’ve been writing a 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. for the 5.8, 6.0, 6.1, and 6.2 releases. It is not uncommon to receive a 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. draft for the first review on the evening before the Field guide is supposed to be published. That is unacceptable. Not to mention the situations when no developer wants to write the Dev note, and then the person who’s writing the Field guide has to do it.

The pressure and overflow of work during this week prior to publishing the Field guide is not healthy. I’d say it’s not even humane.

Developers working on new features should have on their mind, from the first line of the code, the documentation of that code. If they are not willing to write the Dev note, then they shouldn’t start writing the code. Otherwise, the requirements for being the docs focus lead should change and require a developer who is also a technical writer.

I’ve said this many times and will continue saying it: It’s not mandatory for developers to know how to write the documentation; they usually don’t. But they have to be able to explain what the code does, how to use it and write a couple of examples. The docs people will make it understandable, readable and wrapped in nice words.

The main problem with documenting each release has been and still is missing communication and timely collaboration between developers and documentarians.
- Aaron Jorbin 8:00 pm on September 12, 2023
  
  > 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. must be drafted much earlier in the cycle.
  
  Perhaps the target should be 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 for all dev notes?
Francesca Marano 7:46 pm on September 4, 2023

publishing it to the final scheduled 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..

I am all for doing this in advance, but as @milana_cap pointed out, it’s not uncommon to get the draft of the 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. very close to the release of the 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..
I recommend against testing a revised timeline for 6.4 since we only have 3 Betas.

[…] We consider what these two “guides” are called to make it as clear as possible what the intent/audience is. Perhaps “Extenders Guide” and “Technical Guide” or some iteration on those?

100 times, yes! But still in the make blogblog (versus network, site) of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., Plugins and Themes.

Developers Blog

I worry that it hasn’t built the readership (yet) to be the main source of truth for Dev Notes, Field Guides, or even a new version of those. I believe the blog is also more suited for tutorials, demos, etc…
- Aaron Jorbin 8:04 pm on September 12, 2023
  
  I worry that it hasn’t built the readership (yet) to be the main source of truth for 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., Field Guides, or even a new version of those.
  
  Isn’t this a bit of a chicken and an egg problem? If the content isn’t being then there will be no readership so there will be no content so there will be readership so…
  - Francesca Marano 10:11 am on September 13, 2023
    
    100%.
    Can we cross-post? To ensure one way or another, people get the guide. Potentially making the dev blogblog (versus network, site) the source of truth and cross-post here.
Birgit Pauli-Haack 3:40 pm on September 5, 2023

@jorbin Thanks for the 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.” and all the thoughts that went into your proposal after the discussion at the Community Summit. There were great points raised and are certainly worth further discussions.

I do worry about duplication and busy work at a time when there is a lot of pressure on the release team as is. I was the 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. wrangler for 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/ repos for 6.0, 6.1 and 6.2. and I echo @milana_cap take on how hard it is to get Dev notes produced.

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. is organized by components but it could include the suggested three sections and highlight at the beginning, following the principle to not ‘bury the lede’, meaning to rearrange it to list the changes with the most impact for the developers at the beginning.

I have the feeling the the “Editor in iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.” feature was not recognized by the documentation team as possibly breaking change. The first version of the 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. did not indicate much of a problem, otherwise it would have been highlighted as such.
Only after the release the ramification were discussed. If that’s what prompted the proposal (and similar situations before), we won’t fix that kind of situation by creating another post about changes in a release.

Like it was mentioned before, the Developer Blogblog (versus network, site) is only a few months old. It has 652 subscribers. The Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blog has almost ten times as many (5,655). We are increasing readership every month, but it’ll take time.

The What’s new for Developers round-up posts, are getting some traction and provide a constant stream of updates for developers. Instead of three times a year with the releases, bit- size information with links to more details goes out every month.

Let’s keep thinking about improving the reach of Developer Blog and in time it might become the #1 resource for developers.
- Aaron Jorbin 8:11 pm on September 12, 2023
  
  > I do worry about duplication and busy work at a time when there is a lot of pressure on the release team as is.
  
  This might be a regional/generational use of the term “busy work” but I understand that to mean work that keeps a person busy but has little value in itself and that is far from the goal here. I think the work being done on the 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 the work being proposed here have a large amount of value, but they have value to different people.
  The What’s new for Developers round-up posts, are getting some traction and provide a constant stream of updates for developers. Instead of three times a year with the releases, bit- size information with links to more details goes out every month.
  
  As I talked about in my reply to Justin, “What is the key information that extenders need to know to be ready for WordPress X.Y” rather than “What changes are happening and being discussed” which the “What’s New” posts answer.
  
  Additionally, the “What’s new” posts are just as long if not longer than the field guide currently is.
Josepha 7:21 pm on September 7, 2023

The 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. is definitely in need of an examination, and I’m so glad to see this discussion happening! I agree with the basic points (too long, unclear audience, varying timeliness & quality). I don’t agree with the conclusion, though (Complete Field Guide on Make/CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. plus an Abridged Field Guide on Dev Blogblog (versus network, site)).

My question is a foundational one that was probably covered in the ad hoc meeting, but since I wasn’t there, I’ll ask it here:

Is a Complete Field Guide and Abridged Field Guide the right point of separation, or is the more appropriate separation somewhere in the defined audiences? All Extenders and All Service Providers, for instance.

And if it is the latter, then wouldn’t the proper publications actually be Developer/News* and WordPress/News respectively?

* This assumes that 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. should introduce/raise awareness of a change but not serve as technical documentation.
Steven Lin 2:52 pm on September 13, 2023

@jorbin , thank you for taking the effort in raising awareness on this topic.

To start. I’m indifferent about the content scope and post length.

I originally made the section summary to be more detailed because I didn’t know the amount of detail that is expected (and there weren’t any instructions available). In written work, if one is unsure about the scope, it’s safer to have more detail than fewer since it’s always easier to reduce the detail than to increase them at the last minute of the publication.

FWIW, here are my positions on some f the issues:

I.) Shall a new document be created dedicated to extenders?

I’ve reservations about this because such document seems to require a different process, on top of the existing work loads of a Doc lead (needing to collect/review all other 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. posts, plus the Doc lead’s own posts).

II.) Should the independent dev note posts be embedded or hyperlinked?

I’m indifferent on this. Perhaps this depends on Doc lead’s need to reduce the post length even further.

With the above said, I wonder if I can propose an alternative format that can perhaps serve as one of the potential solutions. If not, it may serve as an intermediate solution (meaning, in the future, for whatever reason the post length becomes too long and there is a shortage of time to reduce it quickly, the Doc lead can utilize such tactic).

=====

The current 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. format in recent versions of WordPress has essentially three parts (this format I inherited from Milana):

I.) Intro + 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 part

II.) Dev Note sections + notable “add-to-field-guide” labelled items from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.

III.) The remaining one sentence length “add-to-field-guide” items from Core Trac (listed below the sub-title “But wait, There Is More”). This section can occupy up to 1/3 of the post length.

There is another post named “Misc. Developer Changes in WP X.Y” which stores many misc paragraph sized 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. for the release.

Since paragraph sized dev notes are typically more important than one sentence length “add-to-field-guide” items. If the post can store these paragraph sized dev notes, it can certainly store one sentence length “add-to-field-guide” items?

I wonder if it’s permissible to move *most* of the “But wait, there is more” section to the “Misc. Developer Changes in WP X.Y” post?

Here’s what the preview of the two posts look like:

preview of “WordPress 6.3 Field Guide (Alternative Format)”
https://make.wordpress.org/core/?p=108040&preview=1&_ppp=e02b6fb5d0

preview of “Miscellaneous developer changes in WordPress 6.3 (Alternative Format)”
https://make.wordpress.org/core/?p=108042&preview=1&_ppp=2004bbea3b

In addition to the above, I’ve also made the following changes:
i.) Addition of the High Impacts/Breaking Changes section near the top.
ii.) I’ve reduced the post length further by switching dev note link format from embeds to hyperlinks.

The resulting post lengths is much shorter, comparable in length to Field Guides in much earlier version of WP. As an comparison, the post length is similar to one of your previous Field Guides:
https://make.wordpress.org/core/wordpress-4-7-field-guide/
Nick Diego 3:53 pm on September 14, 2023

While this does not address the proposal directly, @greenshady and I (and others) are going to begin running developer-focused Hallway Hangouts to discuss the major upcoming changes coming with each major WordPress version.

We are in the process of finalizing and scheduling “What’s new for developers in WordPress 6.4” for mid-October.