Priority levels of Issues

Last modified: December 29, 2008 - 13:45
Critical
When a bug renders a module, a core system, or a popular function unusable. Possible examples from core are the inability to create a new node or blocks won't display. These are to be fixed immediately because the software is not usable at all. Basically if the project (core, module, theme, etc.) can't be used as intended, then it is a critical problem.

For Drupal core, a major version (like Drupal 6.0 or Drupal 7.0) won’t be released until all critical bugs are fixed. For point releases (like Drupal 6.1 or Drupal 6.2), critical bugs won't hold back a release if a security fix is needed. In contributed projects, it is up to each maintainer how they would like to handle the critical status and whether that will stop them from creating a release.

Normal
Bugs that just affect one piece of functionality. We could even release with these. An example here might be the category filter not working on node admin screen.
Minor
This is most often used for cosmetic issues that don't inhibit the functionality or main purpose of the project.

Setting priorities for Statuses

Tasks and Feature Requests should never be marked “critical”. They should always be “normal” or “minor”. A support request can be marked “critical”, but the more-urgent priority is unlikely to give you better support; it is better to describe your issue thoroughly to help people understand what is wrong.

For a summary overview of all the elements on the "Submit issue" form, see the Issue Submission Form Description page.

 
 

Drupal is a registered trademark of Dries Buytaert.