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 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.
TODO: Milestones, releasesDevelopment cycle is the same for every release: There are development milestones. Those are usually three milestones M1, M2 and M3. Each milestone will introduce new functionality. There is a dedicated time for bugfixing at the end of each milestone. That's where major-priority issues are addressed.
Last development milestone 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.
Development milestones were introduced in midPoint 4.0 release. Therefore please allow some time for the development process to adapt to this new regime. Therefore the times and procedures indicated above may slightly vary during the first few releases in the 4.x family. We kindly ask for patience and understanding. We are doing our best, but developers are people too.
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.