Proposal to change the user documentation workflow

The workflow currently used by the Docs team to update user documentation is likely a key reason why documentation is often not ready by release day.

Current Workflow Overview

The 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 template contains 13 status columns, intended to reflect multiple review stages before publishing on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Some columns are used for Dev Notes, while others are for user documentation:

• No Status
• Unknown
• To Do
• In Progress
• F.G. and Misc.
• Needs 1st Review
• Needs 1st Review (Peers)
• Edits After 1st Review
• Needs 2nd Review
• Needs 2nd Review (Copy)
• Reviewed: To Revise / Migrate
• Ready to Publish: Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
• Done

Problems with the Current Workflow

Currently, once the Source of Truth article is available, contributors begin writing drafts—usually in Google Docs. These drafts often sit more than a week waiting for a first review. After revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., they then wait again for a second review.

Sometimes the second reviewer publishes the article in WordPress; other times, articles wait weeks longer, and by the time they are updated, the release has already shipped, forcing additional updates.

This process leads to:

• A growing backlog of unfinished documentation,
• articles being updated out of release order (e.g., 6.4 → 6.6 → 6.5), resulting in confusion,
• inconsistent documentation when users report outdated content

Proposed Workflow Change

For WordPress 6.9, the HelpHub documentation was written directly in WordPress, scheduled for release day, without review waiting time.

To ensure accountability, issues were still created in GitHub to track both new and updated articles, and reviews should occur after publication.

Recommendations

• Skip most review stages before release.
• Form a small writing team dedicated to each release.
• Reviews should be optional before publishing (if a reviewer is available.)
• Schedule completed articles to publish on release day.
• Perform a second review after publishing, correcting any issues as needed.
• Simplify the GitHub project template to remove unnecessary review columns.

Key improvements shown by the new workflow

Before	After
Multiple review bottlenecks	Streamlined review — optional pre-release
Work stored in Google Docs	Work completed directly in WordPress
Delayed publishing	Release-day publication
Articles often outdated before launch	Quick updates post-launch
Large backlog that rarely clears	Continuous improvement, smaller backlog