---
tags: prioritization
---

# Priority levels.

As the compiler team's resources are limited, the prioritization working group's main goal is to identify the most relevant issues to work on, so that the compiler team can focus on what matters the most.

## Words used in this document:

`T-compiler triage meetings` refers to meetings that occur every Wednesday at 18.00 UTC in the `t-compiler/wg-prioritization` stream on Zulip.

`issue` refers to bugs and feature requests that are nomitated for prioritzation, by flagging the `I-Prioritize` label as described below.

This document will define what each Label means, and what strategy for each label will be used.

## Labels

Labeling an issue as `I-Prioritize` starts the prioritization process, which will end by removing the `I-Prioritize` label and appending on of the 4 labels we will discuss below:

* P-Critical
* P-High
* P-Medium
* P-Low

Each of these labels defines a strategy the team will adopt regarding:
* The amount of focus a given issue will receive
* Check-in frequency: Whether and how often often it will be discussed during the T-compiler triage meetings
* How members of the community can get involved

## Definitions

### P-Critical

A `P-Critical` issue is a potentially blocker issue.

The Working Group will keep track of the number of such issues open at the same time (which shouldn't be more than 5), and how long such issues remain open.

Examples of things we typically judge to be “critical” bugs:
* Regressions where code that used to compile no longer does
* Mitigating conditions that may lower priority:
* If the code should never have compiled in the first place (but if the regression affects a large number of crates, this may indicate that we need a warning period)
* If the code in question is theoretical and considered unlikely to exist in the wild, or if it only exists in small, unmaintained packages that are not widely used
* If a regression has been in stable for a release or two (either because we are still awaiting a fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as well, because by that time, if the users have not raised a ruckus about the regression, that is a sign that it is inherently not a critical issue. Eg: [an issue that would have been P-Critical but ended up being P-High](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818)

* Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed)
* Mitigating conditions that may lower priority:
* If code uses feature that is explicitly not specified (e.g. `std::vec::Vec` docs state order in which it drops its elements is subject to change)
* Feature-gated features accessible without a feature gate
* Mitigating conditions that may lower priority:
* If the pattern is VERY unlikely
* Soundness holes where common code that should not compile actually does
* Mitigating conditions that may lower priority:
* Soundness holes that are difficult to trigger
* Soundness holes that have been around for a very long time may be critical, but typically require
* Diagnostic regressions where the diagnostic is very common and the situation very confusing
* ICEs for common scenarios or code patterns
* Mitigating conditions that may lower priority:
* If the code that triggers the ICE also triggers compilation errors, and those errors are emitted before the ICE
* If the code in question makes use of unstable features, particularly if the ICE requires a feature gate

### P-High

`P-High` issues are the ones the compiler team will focus on the most.

They can be `P-Critical` issues that have a mitigating condition as defined above, or important issues that aren't deemed blockers.

The effectiveness of the prioritization Working Group will be a direct consequence of our ability to draw the line between `P-Critical` and `P-High` issues.

### P-Medium

`P-Medium` refer to issues that aren't critical, and that will be resolved in the long run. Eg issues that will be fixed after a specific feature has landed.

### P-Low

`P-Low` bugs are bugs that don't cause soundness or safety issues, and that occur in a "failing path" already. Eg: Code that wouldn't compile and raises an error. It might also refer to features that would be nice to have, but aren't deemed a priority

## Amount of focus a given issue will receive
### P-Critical

A P-critical issue will receive the most attention. It must be assigned one of several people as soon as possible, and the rest of the team should do their best to help them out if/when applicable.

### P-High

P-High issues are issues the teams will mostly work on. We want to make sure they're assigned, and keep an eye on them.

### P-Medium

P-Medium issues won't be our focus. They are issues we would mentor someone interested in fixing.

### P-Low

P-Low issues won't be our focus. They will remain in this state until someone complains, a community member fixes it, or it gets fixed by accident.

## Check-in frequency
### P-Critical
P-Critical issues will be discussed at every weekly T-compiler triage meeting until either:
- The issue is complete.
- The issue gets deprioritized.

### P-High
P-High issues won’t be discussed at every weekly meeting, but must be kept in mind. We might want to discuss them biweekly or monthly, to try to ensure progress, and reassign the bug to someone new if there is something blocking the current assignee.

### P-Medium
P-Medium issues won’t be discussed during weekly meetings. Maybe we can run a broader triage session every 3 months or just after a release to check if some issues should change priority for the next release efforts.

### P-Low
P-Low issues won’t be discussed at all during weekly meetings. P-Low issues can either change priority at some point, or be fixed, or be closed as "won't fix"

------------------------------------------------------------------------------

###### Questions and comments about this document can be added below, or in the relevant [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/What.20is.20the.20meaning.20of.20each.20priority.20level.3F).
######