There are a number of keywords with a defined meaning. These are commonly used to manage the workflows of specific tickets, as well as releases, and to generate reports. Keywords should not be thought of as generic “tags,” which are not necessary.
This keyword signals that the ticket would be a good starting point for new contributors to get used to the process before tackling more complicated tickets.
A proposed solution to the ticket has been attached, and it is ready for review.
The ticket has been reviewed, found to be desirable to solve, and marked as especially needing a patch, or the submitted patch doesn’t work and needs to be redone.
A submitted patch no longer applies cleanly to the WordPress core files, usually because nearby code has been modified since the patch was submitted. The patch needs to be merged and re-submitted.
The ticket has been reviewed, found to be desirable to solve, and the latest patch contains unit tests. Like needs-unit-tests, this keyword indicates the proposed changes constitute a high risk of causing other issues.
The ticket has been reviewed, found to be desirable to solve, and we would like some unit tests written to test the functionality and any patch that may exist before committing a change, as the risk of causing other issues is high.
Inline documentation for the code is needed. These are either place holder tickets for individual files, or tickets with patches for new functions which need documenting before they are committed.
Documentation in the Codex needs updating or expanding. Remove the keyword from the ticket once the Codex is updated.
Patches and commits that change UI need screenshots. Document visual iterations. Upload screenshots directly to the ticket or post to make/flow for more involved visual documentation such as visual records or visual surveys. Cross-link any make/flow posts with the ticket. Remove the needs-screenshots keyword from the ticket once screenshots for both a desktop and a phone, at the least, are provided. Full context screenshots taken on physical devices are preferred. New patches require new screenshots. Once a ticket has at least one of the needed screenshots, tag it with has-screenshots. #needs-screenshots
Serves as a partner to needs-screenshots. Once a ticket has at least one screenshot, tag it with has-screenshots. If more screenshots are needed, leave needs-screenshots on the ticket until all screenshots are provided. #has-screenshots is used to create visual changelogs and the Today in the Nightly posts. Do not clear this tag from closed tickets. has-screenshot and needs-screenshots are part of the post-commit diligence lifecycle and are expected to exist on closed tickets. need-screenshots exists temporarily until all screenshots are provided and has-screenshots exists permanently.
This keyword should only be applied by committers. The keyword signals that the ticket is a priority, and should be handled early in the next release cycle.
The ticket is a candidate for closure with a disposition other than fixed (i.e. wontfix, worksforme, invalid, or duplicate). Often seen with reporter-feedback or 2nd-opinion; otherwise, the ticket would have been closed in lieu of adding the close keyword.
This change is one that warrents a dev note on the make core blog. If a change is significant new functionality, a large refactor, or includes a breaking change, it always requires a dev note.
A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.
A response is wanted from a core developer or trusted members of the development community.
Another person is needed to express an opinion about the problem or the solution.
One or more people are needed to test the solution. When testing a patch, please comment with the patch filename that was tested, how the patch was tested, and which version of WordPress was used (including the SVN revision number, if it is not an officially released version).
ui-feedback and ux-feedback
A response is needed from the core team with regards to the desired user interface or experience.
The patch has been reviewed and tested by a trusted member of the development community; therefore, the patch should be considered a commit candidate, and is ready to be added to the WordPress core files.
Only used late in the development cycle (after string freeze) to track potential string changes, as translators need to be notified.
Only used late in the development cycle (after a branch has been created for a release) to indicate that an issue has been “fixed” in the next “major” version (trunk) and needs to be merged back to the branch for the upcoming release by a permanent committer. (There is also “fixed-minor” which indicates that an issue needs to be merged back into trunk from a minor release branch; more info about these keywords here.)
After a branch has been created for a release, each change (except for build and test suite changes) needs to be reviewed by two permanent committers. The first reviewer should set the keywords “commit dev-feedback”, and the second reviewer should set the keywords “commit dev-reviewed”.