Trac Workflow Keywords

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 Status-based Keywords

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 ticketticket Created for both bug reports and feature development on the bug tracker. would be a good starting point for new contributors to get used to the process before tackling more complicated tickets.

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

A proposed solution to the ticket has been attached, and it is ready for review.

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.

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

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

Documentation in the Codex needs updating or expanding. Remove the keyword from the ticket once the Codex is updated.

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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility)./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, 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. #needs-screenshots

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

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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. cycle.

close

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

Top ↑

Action-based Keywords Action-based Keywords

reporter-feedback

A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.

dev-feedback

A response is wanted from a core developer or trusted members of the development community.

2nd-opinion

Another person is needed to express an opinion about the problem or the solution.

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

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 blogblog (versus network, site). 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 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..

has-dev-note

A dev note has been published on the make core blog outlining this change. This change provides significant new functionality, a large refactor, or includes a breaking change.

needs-privacy-review

Input is needed from the core privacy team with regards to the privacy implications of the suggested changes.

has-privacy-review

Input has been given from the core privacy team reviewing the privacy implications of the suggested changes.

needs-copy-review

Input is needed from a copywriter with regards to the suggested verbiage changes.

has-copy-review

Input has been given from a copywriter reviewing the suggested verbiage changes.

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.

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.

fixed-major

Only used late in the development cycle (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) 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 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..  (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 here.)

dev-reviewed

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

Last updated: