Following table summarizes the priority system used in midPoint development and support:
|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 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 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 requests or when a developer with a special skill is temporarily unavailable. The times may be a bit longer in such cases.
Security issues are always the highest priority, no matter who is the reporter. When reporting issue to the issue tracker please clearly indicate that this is an security issues (e.g. use word SECURITY in the title). Appropriate priority will be set be the developer reviewing the issue. If the issue report is sensitive and it may put others at risk then you can use our responsible disclosure mail address firstname.lastname@example.org. See Security Guide page for more details.
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.