Current Workflow Overview
The GitHub 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.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 Core 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 revisions 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 |
Leave a Reply