Last updated May 26, 2014.

Contributors use the field "Issue tags" of the issue to classify or group related issues so they can organize issues effectively.

General guidelines for creating tags

  • When adding a tag, please choose from among the already existing tags, listed here:
  • Don't create a new tag, unless you are the project maintainer or have been asked to. Select one of the existing options instead, if appropriate.
  • Check your spelling and formatting carefully to ensure you are not inadvertently creating a new tag. (Also, # breaks the autocomplete and should not be used.)
  • Don't use terms that appear in the hard-coded issue fields as component, assigned, priority, status, or title.

Guidelines for contributors who tag issues

You can use tags for:

  • Tracking issues for initiatives that span multiple projects. E.g. git phase 2 or redesign
  • Narrowing issue lists when searching by combining 2 existing tags and ANDing them together. For example, using the two tags: D8MI, sprint, is preferable to creating a new single tag such as D8MI high-priority.
  • Grouping issues within a single project that span multiple components. E.g. core's usability issue queue
  • Classifying issues with more detail than the status, especially defining what exactly "needs work". E.g. needs tests or needs documentation
  • Tracking "milestones", e.g. the Project module's 6.x-1.0 blocker issue queue or issues targeted for implementation during git sprint 4
  • Classifying issues by other criteria than the hard-coded default fields. For example:
    • Defining how difficult some tasks on certain issues are expected to be, e.g. novice issues
    • Tracking (and at times debating) if an issue qualifies as an API change, if it
      breaks the string freeze, etc
    • Classifying an issue as FAQ when another issue is closed as a duplicate of it