Joomla! Documentation™

In order to understand how issues and bugs are tracked by priority, here is a common scenario.

You've been trying to solve it for hours, no one on the forums has been able to help, the issue seems not to be covered in the documentation, and you are probably on a deadline too. Time to submit it to the tracker. After all that effort, it sure seems like a critical issue. So, you select a priority level of high.

Then what happens? Someone from Joomla! Bug Squad (JBS) changes it to a medium priority. Why did they do that? Does that mean your issue isn't important and it won't be dealt with? Are they just mean and uncaring? Of course not. It just turns out the development work group has strict definitions of priority levels.

Priority Definitions

Issues (bugs) are prioritized according to the following characteristics:

Priority 1 → Critical

The trunk is not working at all. Significant parts of the source are broken preventing key operations. Examples are login, installation, extension installers, JavaScript errors that prevent you from moving a save or similar action, etc. Also includes the generation of Fatal PHP errors.

Priority 2 → Urgent

Parts of the source are obstructing operation in a serious way or causing a major loss in advertised function.

Priority 3 → Medium

Issues that are hindering advertised behaviour but the application is still workable. Examples would include parameters not working as advertised, language files not loading as expected and so on.

Priority 4 → Low

Minor loss of function and generally annoying behaviour. May include less common platform or browser specific problems that while they may be technically major in those environments, represent a minority. Also includes missing translation strings.

Priority 5 → Very low

Cosmetic problems, misspelled words, graphically misaligned object, less common issues with parameters, etc.

What Does This Mean?

First of all, if it is not within the first few days of a release and it doesn't involve a security issue, unless you are using Subversion or a nightly build you will most likely never see a priority 1 (high) issue or need to report one. That's because if there are any open priority 1 issues in the codebase, there will not be a release. The same thing goes for priority 2 (urgent). A real priority 1 issue in an actual release is something that would trigger a new release. A priority 1 or priority 2 issue in a branch of the codebase would keep a scheduled release from taking place. This is serious because each release contains many bug fixes and improvements. Not releasing keeps most of the community from getting those. Forcing an unscheduled release is serious too because it means that work on other things stop while all efforts are put into getting the release ready.

The one exception would be if you discover a major security issue, but the tracker is not the place to report most security issues.

This doesn't mean that there are never priority 1 or 2 issues. Example priority 1 issue here Read More link does not appear on Category Blog Layout.

Before you decide to mark an issue as priority 1 or priority 2, think about whether it would really warrant all of these things.

Most issues are priority 3, medium. However some issues are priority 4 or 5. If you mark your issue as priority 4 or 5, does that mean it will not get fixed? Not at all. If it's an easy-to-fix issue (especially if you provide a patch or proposed code) it may get taken care of right away. Some people in JBS informally specialize in language issues, CSS or other topics that are often in priority 4 or 5 issues. Don't feel like you need to mark something priority 3 for it to get attention.