content/community/contribution-guides/priority-guide.adoc (37 lines of code) (raw):

--- title: "Issue Priorities" --- == Issue Priorities === Priority 0: Outage This is reserved only for the most critical of bugs halting all development on the project. *Example Priority 0 issues*: - the build is broken, halting all development - the website is down - a vulnerability requires a point release ASAP === Priority 1: Critical This is considered a high priority. Most P1 bugs should block a release. P1 bugs should not be unassigned and require frequent status updates. *Example Priority 1 issues*: - regression in integration tests - important component is nonfunctional - performance regression === Priority 2: Default Most tickets fall into this priority. These can be planned and executed by anyone who is interested. No special urgency is associated, but if no action is taken on a P2 ticket for a long time, it indicates it is actually just P3/nice-to-have. *Example Priority 2 issues* - typical feature request - bug that affects some use cases but don't make a component nonfunctional === Priority 3: Nice-to-have Nice-to-have improvements. *Example Priority 3 issues* - feature request that is nice-to-have - ticket filed as P2 that no one finds time to work on === Priority 4 Nice-to-have improvements that are also very small and easy. Usually it is quicker to just fix them than to file a bug, but the issue can be referenced by a pull request and shows up in release notes. *Example Priority 4 issues* - spelling errors in comments or code - sonar code smells