Last updated April 21, 2015.
Also see the handbook page on Issue Categories (bug, task, feature request, support request).
- Critical (#)
- Bug (#)
Critical bugs include those that:
- Render a 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.
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. (See the critical performance issue criteria for Drupal 8.)
- 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 PHP error which is only triggered under rare circumstances or which affects 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 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 priority is most often used for cosmetic issues that do not inhibit the functionality or main purpose of the project.
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.