Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Following table summarizes the priority system used in midPoint development and support:

PriorityWho can reportUsually used forTypical reaction time
(but no gurantees)
BlockersubscriberIssues that block everything and everybody.
Production environment is down.
Financial or reputation damage imminent.
Security issue.
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.
This priority is reserved for issues that affect production environment. Do not abuse this priority for issues that only affect testing or development environments. This priority is not applicable for deployment projects that have not yet reached production phase. Exception to this rule are possible only in very severe cases and only for platform subscribers.

CriticalsubscriberDangerous situation.
Production environment is affected in a non-trivial way.
Risk of financial or reputation damage.

Quick (hours, days)
Must be addressed within development milestone.

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.
This priority is recommended for issues that affect production environment. Do not report issues with this priority that affect only testing or development environment, unless such issues are extremely serious. Use of this priority for deployment project is justified only if the issue blocks entire deployment team and the engineers are not able to proceed with any deployment tasks. Risk of project delays does not justify use of this priority. Deployment project should plan for sufficient reserves for issues discovered during the deployment.
MajorsubscriberUncomfortable situation.
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.
This is the highest priority to use for issues that affect testing and development environments, which is also the highest priority for deployment projects (given the exceptions mentioned above).
Minorsubscriber, communityMinor 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.
Trivialsubscriber, communityCosmetic 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.