Welcome to the official home of the WordPress Documentation Team.
This team is responsible for coordinating all documentation initiatives around WordPress, including the handbooks and other general wordsmithing across the WordPress project.
Want to get involved?
Start here to find out more about what we do and how to contribute:
Documentation Issue Tracker on GitHub: Submit any Documentation Team-related issues on GitHubGitHubGitHub 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/
Weekly meetings
Join our discussions of documentation issues here on the blog and on Slack.
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 filterFilterFilters 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.
The Documentation issue tracker repository is connected to several project boards via automatisation, but also, some processes inside the repo itself are automated.
[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.
