Last updated 5 May 2017.

Also see the handbook page on Issue Categories (bug, task, feature request, support request).

Critical (#)
Bug (#)

Critical bugs include those that:

  • Render a site unusable and have no workaround.
  • Cause loss/corruption of stored data. (Lost user input, e.g. a failed form submission, is not the same thing as data loss and in most cases is major).
  • Expose security vulnerabilities.
  • Cause tests to fail in HEAD on the automated testing platform for any supported environment (including random failures), since this blocks all other work.
  • Cause race conditions, database deadlocks etc. for which even code with 100% automated test coverage may be affected

Regressions in functionality are not automatically considered critical. Even if the bug existed before, it should be prioritized according to its impact.

Task (#)

Drupal core release managers may identify certain strategically important non-bugs as release blockers for a particular release, for example:

  • Severe performance issues. A performance issue is critical by itself if some of the following are true:
    • There is concrete performance issue identified by profiling (MySQL, PHP or browser equivalent) and a viable plan to resolve it
    • The issue affects runtime operation of site, including site administration
    • It can't be committed to a patch-level version (8.0.0 => 8.0.1)
    • Over ~100ms or more savings with cold caches
    • Gets measurably worse with lots of contrib modules or large data sets (e.g. non-indexed queries) and would have to be deferred to a minor version
    • For the installer, the issue causes out-of-memory errors, 503 errors, etc. that make it impossible to install Drupal reliably, or improves installer performance by an order of magnitude (say from 4 minutes to 25 seconds).
    • Other specific issues at branch maintainer discretion
  • Significant regressions in user experience, developer experience, or documentation (at the core maintainers' discretion).

When a core maintainer decides that an issue should not block a release, its priority is downgraded accordingly.

Impact of critical issues on releases

Major versions of Drupal core (like 7.0 or 8.0.0) won't be released until all critical issues are fixed. Minor and patch versions (like 8.1.0, 8.0.1, and 7.1) are not blocked by critical issues.

In contributed projects, it is up to each maintainer how they handle the critical priority.

Major (#)

The major priority is used for issues that are not critical, but that do have significant impact or are important by community consensus.

These issues are prioritized in the current development release and backported to stable releases where applicable.

Major issues do not block point releases.

Bug (#)

Bugs that have significant repercussions but do not render the whole system unusable (or have a known workaround) are marked major.

Major bugs include those that:

  • Interfere with normal site visitors' use of the site (for example, content in the wrong language, or validation errors for regular form submissions), even if there is a workaround.
  • Trigger a PHP error through the user interface, but only under rare circumstances or affecting only a small percentage of all users, even if there is a workaround.
  • Render one feature unusable with no workaround.
  • Block contributed projects with no workaround.
  • Cause a significant admin- or developer-facing bug with no workaround.
  • Cause user input to be lost, but do not delete or corrupt existing data.
  • Cause test failures in environments not supported by the automated testing platform.
Task (#)

Examples of major tasks:

  • code refactoring like removing Taxonomy term reference field in favor of Entity reference, or
  • adding a Drupal Yaml wrapper.
Feature Request

Examples of major features:

  • providing a better UX for creating, editing & managing draft revisions.
Normal (#)

Normal issues are those that are not Critical or Major; they have isolated impact and may have workarounds. Most issues are considered normal.

Bug (#)
Bugs that affect one piece of functionality and are self-contained are normal priority. They do not impact the overall functionality of the software.

Examples of normal bugs:

  • Admin- or developer-facing bugs with a workaround.
  • Bugs for site visitors that do not interfere with site use, for example, visual layout issues.
  • The category filter not working on the database log screen.
Task (#)

Examples of normal tasks:

  • styling fieldset elements,
  • cleaning up css (causing no change the UI),
  • adding a test for a small piece of code that works but is untested,
  • replacing code that works with code that is the current best practice, or
  • improving the naming of classes.
Feature Request (#)

Examples of normal feature requests:

  • adding a "Create content type" link to the content listing page.
Minor (#)

Minor priority is most often used for cosmetic issues that do not inhibit the functionality or main purpose of the project.


Examples of minor bugs:

  • An incorrect class reference only in a comment.

Examples of minor tasks:

  • Typos in code comments
  • Formatting or whitespace issues.

Choosing the right priority

Each project's maintainer might have specific guidelines for that project. In the end, it is up to maintainer discretion to decide issue priorities.

Feature requests are very rarely "critical". They should usually be "normal".

Support requests should never be marked "critical" or "major". (It remains possible in the UI though to handle contrib special cases.) If you believe you have run into a bug and it is preventing your site from working at all, post it as a bug report; however, be prepared for others to re-categorize it as appropriate. A higher issue priority is unlikely to give you better support; it is better to describe your issue thoroughly (with clear steps to reproduce it) to help people understand what is wrong.