Last updated 4 February 2017.

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.
  • Don't remove Topical issue tags unless the topical tag does not apply anymore E.g. An issue tagged Documentation is not related to Documentation so it is okay to remove. Sprint tags and the "Novice" tag are helpful for sprint organizers and issue triage even if the issue is fixed or a sprint is over, and should not be removed. You should use the issue status to filter out fixed issues instead.

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