Write: Document a WordPress Release

Function: Write
Type: Team

This pathway describes how the Documentation team prepares, publishes, and maintains documentation for a major WordPress release. Following a consistent process ensures users and developers have accurate, up-to-date information when a new version ships.

This work is tracked in the Documentation Issue Tracker, discussed in #docs, and coordinated with the release squad in their dedicated 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/ channel.

Note: This process is actively evolving and may change from release to release.

Before you start

Complete the common setup first, then:

• Setup: Set up WordPress Playground to explore features, take screenshots, and verify changes. If writing directly to HelpHub, request access in #docs — otherwise, draft in a Google Doc and share the link.
• Read: Documentation process during a major version release, releasing major versions (core handbook), publishing the Field Guide, Documentation Grammar Guide, Style and Formatting Guide, Tone and Voice Guide, External Linking Policy, and screenshot best practices.
• Connect: Join #docs on Slack. Volunteer during a weekly Docs team meeting when the call goes out. Less experienced contributors are encouraged — you may be paired with a mentor.

Steps

During the release cycle

1. Set up the project. Create 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 by the repository owner. https://github.com/ project in the Documentation Issue Tracker to track all work for the release (e.g. the WordPress 6.9 Documentation project). List both DevNotes and user docs.
2. Identify what needs updating. Review the release roadmap shared at the start of the cycle. At each stage (Roadmap → 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 → RC1), the list narrows. For each item, decide whether it needs a new document or an update, open an issue with the release-specific label, and add it to the release project.
3. Write documentation. DevNotes are written by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers; user docs are written by docs team members. When writing user docs, match the style of existing documentation for similar features. Always update screenshots and include a changelog at the bottom of every document. Use Playground to verify — don’t rely only on reading PRs.
4. Review documentation. When writing is done, change the issue status to “Needs 1st Review” under Projects. Share in #docs that work is ready.

DevNotes and the Field Guide

• Each DevNote requires two reviews: one technical (accuracy) and one copy (grammar/spelling).
• Space DevNotes out — no more than three published on the same day.
• All DevNotes should be published before RC1.
• At RC1, compile all DevNotes into the Field Guide, which is linked from the WordPress admin About page, the release announcement, and the HelpHub version page.

Preparing for release day

1. Create the HelpHub version page. Duplicate the previous version’s page (e.g. Version 6.8) and update: jazz musician name (provided on release day), announcement link, db_version and TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. revision (from the release team Slack channel), ticket list link, release squad, and changelog (from the Triage Lead or Tech Lead — can be added later if needed).
2. Schedule publication. Schedule all completed articles for release day. Publish only after the official announcement — ideally within 30 minutes. Publish everything at once rather than staggered.

Release day

1. Update key pages in order. Follow the publishing order defined in the documentation process handbook:
   1. HelpHub Version page (under WP Versions)
   2. WordPress Versions page — version link, release date, musician name, changelog, announcement, db_version, and update “Planned Versions”
   3. Roadmap page
   4. History page
   5. Origins and version history page

After the release

1. Continue documentation work. The team continues updating and writing user docs post-release. Reviews happen post-publication and issues are corrected as needed. For minor releases, only create the HelpHub version page and update the WordPress Versions page.

Tips

• Coordinate with the release squad as much as needed — for progress updates, confirming what needs documenting, and flagging if help is needed.
• Use WordPress Playground to explore features and take screenshots. Features can change drastically during the cycle, so always test the actual release.
• When unsure whether something needs a new document or an update, ask in #docs.
• Stay informed by reading meeting notes on the Make WordPress Documentation blog.

Contribution checklist

• [ ] Release project created in the Documentation Issue Tracker with all items listed
• [ ] All features identified and documented or triaged
• [ ] DevNotes received two reviews each (technical + copy) and published before RC1
• [ ] Field Guide compiled and published at RC1
• [ ] User docs match the current version, with up-to-date screenshots
• [ ] HelpHub version page complete (musician, announcement, db_version, revision, changelog)
• [ ] All documentation published within 30 minutes of the official announcement
• [ ] Key pages updated in the correct order on release day

What happens next

After the release, continue updating any remaining user docs and review published documentation for post-publication issues. Monitor the release project board and #docs for feedback.

When the next release cycle begins, the process starts again. Volunteer early to get involved.

Help

Stuck? Check the getting help guide, then ask in #docs.