Bug and Issue Tracker Priority
From Joomla! Documentation
Revision as of 07:39, 24 October 2018 by Franz.wohlkoenig (talk | contribs)
In order to understand how issues and bugs are tracked by priority, here is a common scenario which occurs often.
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) goes and 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 pretty strict definitions of artifact priority levels.
Issues (bugs) are prioritized according to the following characteristics:
Priority 1 → Critical
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, etc.
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, they represent a minority. Also include missing translation strings.
Priority 5 → Very low
Cosmetic problems, mis-spelled words, graphically mis-aligned 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 actually 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 codebase would keep a scheduled release from taking place. This is serious, because each release contains many bug fixes and improvements, so 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 stops 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.
So, 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 or CSS or other topics that are often in priority 4 or 5 issues. So don't feel like you need to mark something priority 3 for it to get attention.