Last updated January 26, 2016.

There are five issue categories on This page explains how they are commonly used in the core issue queue. Usage may vary between contrib projects.

The issue categories are combined with priorities (critical, major, normal, minor). There is often a fine line between "major task" and "normal bug", or "normal task" and "major feature request". However, it should be easier to compare "major task" and "major bug" using the definitions below.

Table of contents

Bug (#)

A bug is a functional error in the system, they can have any priority from minor to critical. While the definition of 'bug' is commonly understood, here are some examples:

  • A PHP error such as a warning or notice
  • Data loss
  • Regressions in functionality from previous major versions or stable releases (this may include missing functionality or APIs if there is no obvious replacement).
  • Race conditions
  • Memory leaks
  • Scalability issues
  • Incorrect or misleading user interface text
  • Incorrect or misleading documentation
  • Usability issues that prevent people from using functionality (as if it didn't work at all).
  • Accessibility issues that prevent people from using functionality (as if it didn't work at all)

Task (#)

Tasks are not functional bugs, but represent things that 'need to be done'. It is very rare for a task to be critical, however some things have to be done 'before release' that are not strictly functional bugs - this mainly applies to major core releases only.

For example:

  • Refactoring code to make it more readable
  • Adding automated tests
  • Refactoring functions for performance (where they are not causing functional errors)
  • Updating code to new APIs
  • Improving coding standards
  • Any 'meta-issue' that is used to group together other issues, which may be bugs and/or tasks.
  • Minor API changes such as adding new hooks.
  • Rewriting user interface strings for brevity and clarity.

Feature request (#)

This is any completely new functionality added to core. Feature requests may be major in scope, but should not be marked as critical since a completely new feature should not block a release.

  • New modules (such as the toolbar module in Drupal 7)
  • New subsystems (such as the Field API in Drupal 7)
  • Adding (or removing!) an option from a particular admin form

Support requests (#)

If you are posting support requests to the core issue queue, you may be better off posting to the forums, or asking in #drupal on irc. Sometimes support requests result from common misconceptions about Drupal (especially install and upgrade), or may turn out to be functional bugs. If there are actionable steps to fix them, they can be converted to bugs or tasks (for example a task in the documentation component).

Plan (#)

"Plan" category is used for meta issues that capture process and give an overview to problems that cannot be solved with one issue. Plan issues will often have multiple sub-steps in related "child" issues (issues that have the plan issue in their "Parent" issue relationship field).