Documentation issue tracker

The Documentation issue tracker is the central place for contributing to WordPress documentation. No actual documentation is hosted in this repository. Its purpose is to track all the issues for any part of WordPress documentation. Therefore, the most used functionality is its issues and automatisation.

Labels

As with any other project management tool, the Documentation issue tracker uses several issue labels for easier filtering out the issues. Depending on what you want to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., you will find labels for various criteria.

Version-based

Some documentation is done as updates for new WordPress releases. These are the numbered labelled, representing the WordPress version.

Some examples are 6.0, 6.1, 6.2 etc.

Project-based

The Documentation team maintains several projects, and each has its label. The main project division is:

• user documentation (HelpHub)
• developer documentation (DevHub)
• advanced administration
• contributor documentation

Developer documentation is further divided into apis, code reference, mobile app, plugins, themes etc., but there are other project labels, such as external links etc.

Status-based

Depending on the status of the issue itself, the repo has four different labels:

• [Status] To do
• [Status] In progress
• [Status] Review
• [Status] Done

Type of work

Labels for the type of work usually represent the amount or complexity of needed work, such as typo, tracking issue (an issue which tracks progress on several related issues), needs screenshots, new document, migration from Codex etc.

Helpers

Helper, or “other” labels, help narrow the search further. Some examples are good first issue, internal tasks, triage etc.

Automatisation

The Documentation issue tracker repository is connected to several project boards via automatisation, but also, some processes inside the repo itself are automated.

Add issues to projects

When certain labels are applied to the issue, the issue gets automatically added to the appropriate project. Some examples are:

• Labels HelpHub feedback and user documentation (HelpHub) will send the issue to the End-user documentation project board. The workflow can be found in .github/workflows/add-issue-to-end-user-docs.yml
• Label 6.3 will send the issue to the WP 6.3 Documentation project board. The workflow can be found in .github/workflows/add-to-6-3-project.yml
• Label advanced administration will send the issue to the Advanced administration handbook project board. The workflow can be found in .github/workflows/add-to-advanced-administration-project.yml
• Label contributor documentation will send the issue to the Documentation team Handbook project board. The workflow can be found in .github/workflows/add-to-docs-handbook-project.yml

On success, the issue will have something like this:

Label issues

Status-based labels are automated in the following way:

• [Status] To do label is applied to every newly created issue. This is set in our issue templates: new-doc.md, doc-issue-fix.md, and helphub-feedback-reports.md.
• [Status] In progress label is applied to the issue when the issue is assigned, AND has [Status] To do label. It is done in label-when-assigned.yml workflow.
• The issue is transferred from [Status] In progress to [Status] Review label when a comment is created and contains /review, AND has [Status] In progress label. It is done in label-when-commented.yml workflow.
• Every closed issue will automatically be transferred to [Status] Done label. This is done in label-when-closed.yml workflow.

Complete work on automated labelling can be found in #882 issue.

The workflow looks like this:

Notify team

Team members in charge of specific documentation projects will be notified in a comment when a label for their project is applied. This is done in notify-team-on-label.yml workflow.

This is an example of the notification: