Last updated May 18, 2013.
The following tags have special meanings when applied to Drupal core issues, often implying a certain workflow:
-
API addition
- Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.
-
API change
-
Changes an existing API or subsystem. Not backportable to earlier major versions, unless absolutely required to fix a critical bug.
-
API clean-up
-
Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.
-
Avoid commit conflicts
-
A large, comprehensive, important patch that is close to being ready to commit, and would be really painful to re-roll if another commit rendered it impossible to apply. Use sparingly! Less important, conflicting commits will be delayed by these issues.
-
Coding standards
-
Involves compliance with, or the content of coding standards. Requires broad community agreement.
-
Commit after thresholds are met
-
Commit this patch when the major/critical thresholds are met.
-
Contributed project blocker
-
Denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.
-
Needs accessibility review
-
Requires reviews and testing to ensure compliance with accessibility standards.
-
Needs backport to D6
-
After being applied to the 7.x branch, should be considered for backport to the 6.x branch.
Note: This tag should generally remain even after the backport has been written, approved, and committed. -
Needs backport to D7
-
After being applied to the 8.x branch, should be considered for backport to the 7.x branch.
Note: This tag should generally remain even after the backport has been written, approved, and committed. -
Needs change notification
-
A change notice needs to be created after this issue has been committed.
Note: There is no need to write a change notification until a patch has been committed that somehow changes the DX (Developer API) or UX (User Interface). -
Needs committer feedback
-
Needs input from the primary project maintainers, because it affects the project's long-term roadmap, or because the community was not able to come to a consensus and needs a top-down decision. Use sparingly.
-
Needs documentation
-
Requires a documentation change elsewhere. For Drupal core (and possibly other projects), once the change has been committed, this status should be recorded in a change record node. (See needs change notification tag above.)
-
Needs issue summary update
-
Issue summaries save patch writers, reviewers and core committers time if they are kept up-to-date. Update issue summary task instructions
-
Needs manual testing
-
The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.
-
Needs profiling
-
May affect performance, and thus requires in-depth technical reviews and profiling.
-
Needs screenshot
-
The change alters the user interface, so before and after screenshots should be added to document the UI change. Make sure to capture the relevant region only (in order to avoid breaking the drupal.org site layout). Use a tool such as Aviary on Windows or Skitch on Mac OS X.
-
Needs tests
-
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
-
Needs update documentation
-
Should be accompanied by a change to the update documentation.
Note: This tag is now deprecated, at least for Drupal Core, because we are using API change nodes instead of a huge monolithic updates page. -
Needs usability review
-
May make Drupal easier to use, but should be confirmed by considering the expectations of new users, as well as Usability experts.
-
Performance
-
Affects performance. Often combined with Needs profiling.
-
Regression
-
Restores functionality that was present in earlier versions.
-
Security
-
Makes Drupal less vulnerable to abuse or misuse.
Do NOT publicly disclose security vulnerabilities; contact the security team instead.
The security team applies this tag to non-critical security improvements not related to known exploits. -
String freeze
-
Affects translatable strings and should be committed before the string freeze milestone of the release cycle.
-
Upgrade path
-
Affects the ability to upgrade Drupal sites to a new major version. Preferred over version-specific tags such as D7 upgrade path.
Comments
Since some initiatives have
Since some initiatives have moved towards a sprint based development model, it might make sense to standardize the way we tag issues for sprints.
I don't know what a good pattern would be, but it seems like this is a tag that a number of initiatives need for informally organizing timeboxing.
Sprint/initiative tags
I've always been on the fence with these tags.
1) There's not really a need for date-specific, location-specific, or sprint-specific tags. To my knowledge, the only reason people are creating them is for "statistical purposes", to see what they've achieved, but that's really a poor argument for flooding our issue tag vocabulary with gazillions of useless entries.
2) After removing dates, locations, and sprint names, there's also not really a need for sprint/initiative specific tags à la "Documentation sprint" or "HTML5 initiative". Issue tags can be combined and ANDed together to achieve the same:
Sprint: April 2011 becomes Needs Documentation, sprint
HTML5 Sprint: August 2011 - 2 becomes HTML5, sprint
I'd really be happy with we could standardize on such tag combinations instead.
However, what originally triggered this discussion was:
3) The removal of a few issue tags named "Issue needs help" and "discussion needed". We have and usually use "Needs architectural review" for that, but you already pointed out in IRC that it's not really about architectural review, but rather the intention is to "touch base" with folks who care and are interested. Normally, we'd just use a simple topic tag for that; e.g., "RDFa" - so everyone who's interested in issues + discussions around that can see all.
4) Your last point of linking together a range of related issues within a queue. No ideas on that.
Daniel F. Kudwien
unleashed mind
Temporary tags are deliberately excluded.
Temporary tags were deliberately excluded from this page. Many of the top 100 tags iin Drupal Core and site-wide were used for temporary initiatives such as the ones you describe, but are are no longer applicable to current issues.
This page is designed to help someone choose appropriate tags for current issues, based on historical consensus. It is not intended to force a consensus where there is none.
Good. — Fast. — Cheap.
(Pick any two.)