|Priority||Who can report||Usually used for||Typical reaction time|
(but no gurantees)
|Blocker||subscriber||Issues that block everything and everybody.|
Production environment is down.
Financial or reputation damage imminent.
|Immediate (hours)||Do not abuse this priority. Developers will drop everything and work on this issue. We will be very upset if this priority is abused.|
It is better to start on lower priorities and escalate as necessary.
Production environment is affected in a non-trivial way.
Risk of financial or reputation damage.
Quick (hours, days)
|Sometimes used by the development team to mark the most important features in a release. MidPoint won't be releases released unless all critical issues are addressed.|
May cause milestone delays. May cause release delays.
Development or project is affected in a non-trivial way.
Risk of financial or reputation damage if the issue is not addressed eventually.
|Appropriate (weeks, months)|
Usually addressed within development milestone.
|Usually addressed within development milestone, but may be postponed to a final stabilization phase (after feature freeze) if needed. Major issues may block releases. But in rare cases even major issues can be postponed to the next release, but that needs to be negotiated with the subscriber.|
May cause release delays.
|Minor||subscriber, community||Minor nuisance.|
Makes life a bit harder, but not a big problem.
Negligible risk of financial or reputation damage.
|Eventual (months, years)|
Usually addressed within a release cycle. But no guarantees.
|Addressed during the final stabilization phase (after feature freeze). Development team will try to address as many minor issues as can fit into the development cycle. But it is almost certain that some of them will be left unsolved and moved out. Minor issue will never block a release.|
|Trivial||subscriber, community||Cosmetic issue.|
Not really important.
Just an idea.
No guarantees. No promises. No estimations.
|Can be freely moved in the plan. The most likely candidate to be moved when the time runs out.|
Times indicate indicated above are the times when a developer starts working on the issue after it is reported. Which means actual developer, not some kind of automated response system that acknowledges receipt of the report. The numbers above are our best estimates that we have about the times and we will try hard to fit into that time. But there may be rare cases, such as when the development team is overloaded by support request requests or when a developer with a special skill is temporarily unavailable. The times may be a bit longer in such cases.
Time to fix is not guaranteed for any issue. We are sorry, but we cannot do that even if we wanted to. Some issues might be fixed in a couple of hours. But it may take days of or even weeks to fix issues that are triggered by exotic configurations, issues that appear randomly, issues triggered by external events and so on. It is impossible to predict how long the fix will take, therefore we simply cannot guarantee that. The priority system is the best we can offer.
Priority abuse: Please, do not abuse the priority system. Attempts to abuse priority system may result in decreasing issue priorities (including subscriber priorities) and/or lower success rates during escalations. We will absolutely hate to do that. Therefore please do not force us to do it. If there is some confusion about appropriate priority it is usually better to select lower priority and explain the situation in the comment. Every new issue is reviewed by midPoint team member. The priority sometimes gets increased during this review if the reviewer thinks that a higher priority is appropriate or if there is a risk that the issue may affect larger number of users.