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.
Status-based Keywords
changes-requested
Feedback has been provided, and the attached patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. needs to be updated.
close
The ticketticket Created for both bug reports and feature development on the bug tracker. is a candidate for closure with a disposition other than fixed (i.e. wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion., worksformeworksforme A resolution on the bug tracker (and generally common in software development) that indicates the bug reported cannot be reproduced., invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally 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.
early
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.
good-first-bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
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.
has-patch
A proposed solution to the ticket has been attached, and it is ready for review.
has-screenshots
Serves as a partner to needs-screenshots. Once a ticket has at least one screenshot, tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) 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.
has-unit-tests
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.
needs-codex
Documentation in the Codex needs updating or expanding. Remove the keyword from the ticket once the Codex is updated.
needs-docs
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.
needs-patch
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.
needs-refresh
A submitted patch no longer applies cleanly to the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. files, usually because nearby code has been modified since the patch was submitted. The patch needs to be merged and re-submitted.
needs-screenshots
Patches and commits that change UIUI User interface 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
needs-unit-tests
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.
phpNN
When paired with the
php-compatibility focus, this manually added keyword identifies the specific PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher version (i.e. NN) that first introduced a compatibility issue or task. For example, php80 keyword identifies that PHP 8.0 is the version that first introduced the incompatibility.Action-based Keywords
2nd-opinion
Another person is needed to express an opinion about the problem or the solution.
commit
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.
dev-feedback
A response is wanted from a core developer or trusted members of the development community. For example, use this keyword when double sign-off is required to backport changes during RC.
dev-reviewed
After a branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a “branch”, such as “the 4.0 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”. If a permanent committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers – a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. created the patch, only one additional review is necessary.
fixed-major
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 (trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running “trunk”, then you are on the latest revision.) 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 releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. branch; more info about these keywords in this post: The keywords “fixed-major” and “fixed-minor”.)
has-copy-review
Input has been given from a copywriter reviewing the suggested verbiage changes.
has-dev-note
A dev note has been published on the make core blogblog (versus network, site) outlining this change. This change provides significant new functionality, a large refactor, or includes a breaking change.
has-privacy-review
Input has been given from the core privacy team reviewing the privacy implications of the suggested changes.
i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.-change
Only used late in the development cycle (after string freeze) to track potential string changes, as translators need to be notified.
needs-copy-review
Input is needed from a copywriter with regards to the suggested verbiage changes.
needs-design
A designer should create a prototype of how the suggested changes should look/behave before writing code.
needs-design-feedback
A designer should review and give feedback on the proposed changes.
needs-dev-note
This change is one that warrants 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 notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..
needs-privacy-review
Input is needed from the core privacy team with regards to the privacy implications of the suggested changes.
needs-testing
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 SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. revision number, if it is not an officially released version).
reporter-feedback
A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.
