Issue Priority field

Last updated on
20 August 2021

This page describes the standard definitions of the options available for the Priority field on Drupal core issues, when applied to each issue category. These guidelines apply to most other projects that are associated with software (contributed modules, contributed themes, etc.). Non-software projects and working groups may use the Priority field in a different way.

Note: for the Drupal core project, unless otherwise noted below, release managers are the final decision makers on issue priority.

List of priority options

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.

Feature (#)

On rare occasions, Drupal core product managers may identify an especially important feature request as critical. In most cases, only core committers should mark a feature request as critical, and it is ultimately up to the product managers to determine which feature requests are critical.

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.

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 (#)

Major tasks often include important API additions, refactors, and other significant changes that are not bugs. Major tasks are often identified by core framework or release managers, initiative coordinators, or subsystem or topic maintainers. If the task affects only one subsystem or topic, the subsystem or topic maintainers determine whether the task should be considered major.

Examples of major tasks:

  • Code refactoring like removing Taxonomy term reference field in favor of Entity reference
  • Adding a Drupal Yaml wrapper
  • Decoupling Drupal core from a dependency that is no longer supported
Feature Request (#)

Feature requests may be marked major based on their value to the project overall and/or the scope of work to complete them. Major feature requests are often identified by core product managers, initiative coordinators, or subsystem or topic maintainers.

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.

Bug

Examples of minor bugs:

  • An incorrect class reference only in a comment.
  • A visual bug that only occurs in a browser that Drupal technically still supports, but will not support in the next release. (For example, a bug in Internet Explorer 11 following the announcement of its end of support in Drupal). 
Task

Examples of minor tasks:

  • Typos in code comments
  • Formatting or whitespace issues.

Choosing the right priority

The guidelines above are for Drupal core. 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" and, as above, they are typically identified by the project maintainer. 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.

Tags

Help improve this page

Page status: No known problems

You can: