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.


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 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.

Top ↑


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.

Top ↑


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

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.

Top ↑


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

Top ↑

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.

Top ↑


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

Top ↑


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

Top ↑

Add issues to projects

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

On success, the issue will have something like this:

Labels and project for the issue.

Top ↑

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:,, and
  • [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:

GitHub bot changing labels for the issue.

Top ↑

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:

GitHub bot comment mentioning Themes project reps because label themes was applied to the issue.

Last updated: