Support Guidelines

Support for midPoint is provided by Evolveum in a form of midPoint subscription which is a commercial (paid) support service. When it comes to reporting a bug or creating feature request the same basic principles apply. This page is summarizing the principles.

MidPoint development team is guided by the information in our issue tracking. The content of issue tracker is the plan. Developers work on the issues tracked there. Strictly speaking, they should work only on the issues files in the issues tracker. Therefore, if you want your bug to get fixed or your feature to get implemented then it has to go into issue tracker. For midPoint subscribers this is often done by the subscriber or partner, as this the best way to maintain communication fidelity. However, it is also a common practice that midPoint developer creates an issue for the subscriber. Regardless of the actual method, all bug reports, feature requests, improvement suggestions and other development tasks must be recorded in the issue tracker to make sure they are addressed.

From the perspective of a support process there is one thing that is more important that anything else: priority. MidPoint development team is guided by issue priorities. MidPoint Development Process is time-based, with one release every year. Releases are planned to accommodate estimated amount of support requests and subscriber features. Release dates are known in advance, and they are not meant to move in any dramatic way. There is no way around the iron triangle. We do not want to compromise on quality and customers are not going pay more than negotiated amount. Therefore, if release dates won’t change, then it is the scope that has to change. Low-priority items are moved out from milestones and releases. This usually affects community issues, as subscriber issues are prioritized. But this principle is also important to estimate when a particular issue will be addressed (including subscriber issues). If the issue has fix version set, then it is likely to be addressed in that version. The latest date when it is fixed is the release date.

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

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.

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 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. However, the priority system is the best we can offer.

One thing which might help to speed up the whole process is to provide as much information as possible to easily replicate the problem. Then, the developer might jump right into fixing the bug instead of spend hours on finding the specific combination of configuration causing the problem. Therefore, please provide complete information about the issue, including logs, configuration, steps to replicate the problem and so on.

This may sound harsh, but there is a good reason for that. We work with L3 issues, which means product bugs, feature requests and similar product-based issues. We do not have the option to "hack" or "work around" the issues that affect only specific configuration. However, deployment engineer may still be able to work around the issue on L2 level. E.g. the issue may be avoided by changing the configuration, isolating midPoint from external events, mitigating effect of the issue and so on. This is where issue resolution times might be predictable. You may have such options because you know your environment, configuration and tolerances. But we do not have such privilege. Therefore, we cannot guarantee fix times.

Developers are free to increase priority of any subscriber issue. Priorities of non-subscriber issues can be changed by developers in any way they seem appropriate, but priorities of those issues are usually going down. If you do not like this, there is a simple way to improve your chances: get midPoint subscription.

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 a security issue (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 security@evolveum.com. 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.

Development cycle is the same for every release: There are development milestones. Those are usually six milestones M1, M2, M3, M4, M5 and M6. Each milestone will introduce new functionality. There is a dedicated time for bugfixing and documentation improvements after every second milestone, after M2, M4 and M6. That’s where major-priority issues are addressed.

Last development milestone (M6) is a feature freeze. This means that all features planned for the release are done. Feature freeze is followed by a stabilization phase. That is the time of a more intense testing. All development efforts are dedicated to bugfixing. All "red" (blocker, critical, major) issues should be addressed at this time. Some "green" issues (minor, trivial) are likely to be addressed as well, but it is almost certain that not all of them will be solved. Remaining issues will be re-planned when release date comes.

MidPoint deployment projects have a lifecycle of their own. There is usually some exploration/preparation phase. Then there is development and testing. Then the project is deployed to production. Then further iterations follow. Characteristics of individual deployment phases considerably vary when it comes to impact and criticality of the issues. We have tuned our support model to provide the right balance for the needs of individual deployment phases. The guidelines are summarized in the following table:

Those guidelines reflect our philosophy that prefers production deployments. While many products and programs are designed to support deployment projects where most of the money is generated, midPoint is quite different. We believe that the most important thing is to keep real (production) midPoint deployments running. The projects that are in the process of deploying midPoint can wait a bit. But production deployments that work with real data cannot wait. They need to have absolute priority.

This may seem harsh for deployment projects. But experienced deployment engineers and managers are already well-equipped for this. The project should proceed in smaller steps, testing the configuration is several iterations (prototyping), the project should have several alternative paths and the project plan should contain sufficient reserves for deployment issues. This is a best practice in the entire IT industry and IDM deployment projects are no exceptions here.

We would also like to emphasize the importance of deployment environments. MidPoint is especially designed for deployments that follow the "three environment model":

Preparing and maintaining those three environments is strongly recommended for all deployment projects. Any significant change to the configuration should proceed from development environment to testing environment and only then it should be deployed to production.

There may be cases when those environments are not used and changes are done directly in production environment. Or cases, where development and testing environments are ineffective because the environment, configuration and data do not reflect the reality of production environment. We do not guarantee that our support services will be ideal fit for such environments. Both midPoint and our services were designed with proper engineering principles in mind and they were designed for deployments where such engineering principles are honored. In case that you are doing configuration changes directly in production environment, you should follow the priority limitations of development/testing environments. In such cases your first reaction to problems should be to roll back the configuration changes and revert to stable configuration. Which solves the problem. The sole fact that this problem was observed in production environment does not justify high priority of the issue.

Most issues cannot be properly addressed unless there is a good cooperation between issue reporter and developer. The developer often needs additional data for the issue. Our usual strategy for all issues is to follow test-driven bugfixing approach. Therefore, we try to reproduce the issue in a controlled environment. Additional data are often needed to achieve that. We expect that it is a responsibility of the reporter to respond to requests for additional data. The usual communication is carried out by the means of comments in the issue tracking system.

We reserve the right to close the issue if the reporter does not respond to communication. More specifically, if there is an issue without any activity for half year, such an issue will be closed.

Those guidelines are designed to benefit the entire midPoint community. We do not look well at those that abuse those guidelines. MidPoint development and support team has finite resources. The abusers may get momentary advantage for themselves, but this approach distracts midPoint team from the tasks that are really important. Therefore, we reserve to lower the priorities for reporters that repeatedly abuse those guidelines. This is the best approach for the entire midPoint community.

All services provided by Evolveum are paid services. There is no free service provided by Evolveum to support midPoint.

However, there is a community communication channel that can be used to discuss midPoint-related topics, in a form of public mailing lists. This is community service, which means it is provided to the community by community. It is not provided by Evolveum. Evolveum only maintains the means of communication (mailing lists) and occasionally participates in the service. But there are absolutely no guarantees regarding any communication in midPoint community.