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.
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.
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 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
has-screenshots is 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.
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.
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.
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.
Only used late in the development cycle (after string freeze) to track potential string changes, as translators need to be notified.
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.