Last updated August 4, 2015.

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

Critical (#)
Bug (#)

Critical bugs include those that:

  • Render the system unusable and have no workaround.
  • Cause loss of data.
  • Expose security vulnerabilities.
  • Cause tests to fail in HEAD on the automated testing platform, 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 regressions. 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
    • It can't be committed to a patch-level version (8.0.0 => 8.0.1)
    • Over ~100ms or more savings with cold caches and would have to be deferred to a minor version
    • Over ~10ms savings with warm caches and would have to be deferred to 9.x
    • Over ~1ms or more with the internal page cache and would have to be deferred to 9.x
    • 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
    • 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) won't be released until all critical issues are fixed.

For point releases of Drupal core (like 7.1 or 8.0.1), outstanding critical bugs will not necessarily hold up a core release. If there are 20 critical issues when 8.0.2 is released, and five of those are fixed, then it may make sense to release 8.0.3 with the other 15 critical issues open - or there may be a security release that has to go out anyway.

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

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.

Examples of major bugs:

  • A non-fatal PHP error, or a PHP error triggered under rare circumstances or affecting only a small percentage of all users.
  • Test failures in secondary environments (for Drupal 7 and 8 core).
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.

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:

  • 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.

Bug

Examples of minor bugs:

  • An incorrect class reference only in a comment.
Task

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.

Comments

Wolf_22’s picture

Support requests should never be marked 'critical' or 'major' - 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 other Drupal.org users to recategorise it as appropriate.

If Support Requests are never to be marked as "critical" or "major", then it might be best to add a restriction somewhere that disables those options if and only if the user selects "Support Request" as their Category.