|
| 1 | +# Priority levels |
| 2 | + |
| 3 | +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. |
| 4 | + |
| 5 | +## Words used in this document: |
| 6 | + |
| 7 | +`issue` refers to bugs and feature requests that are nominated for prioritization, by flagging the `I-prioritize` label as described below. |
| 8 | + |
| 9 | +This document will define what each label means, and what strategy for each label will be used. |
| 10 | + |
| 11 | +## Labels |
| 12 | + |
| 13 | +Labeling an issue as `I-prioritize` starts the prioritization process, which will end by removing the `I-prioritize` label and appending one of the 4 labels we will discuss below: |
| 14 | + |
| 15 | +- P-critical |
| 16 | +- P-high |
| 17 | +- P-medium |
| 18 | +- P-low |
| 19 | + |
| 20 | +Each of these labels defines a strategy the team will adopt regarding: |
| 21 | + |
| 22 | +- The amount of focus a given issue will receive |
| 23 | +- How members of the community can get involved |
| 24 | + |
| 25 | +## P-critical |
| 26 | + |
| 27 | +A `P-critical` issue is a potentially blocker issue. |
| 28 | + |
| 29 | +The Working Group will keep track of these issues and will remind the compiler team on a weekly basis during the triage meeting. |
| 30 | + |
| 31 | +Examples of things we typically judge to be “critical” bugs: |
| 32 | +- Regressions where code that used to compile no longer does |
| 33 | + - Mitigating conditions that may lower priority: |
| 34 | + - 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) |
| 35 | + - 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 |
| 36 | + - 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) |
| 37 | +- Regressions where code still compiles but does something different than it used to do (dynamic semantics have changed) |
| 38 | + - Mitigating conditions that may lower priority: |
| 39 | + - 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) |
| 40 | +- Feature-gated features accessible without a feature gate |
| 41 | + - Mitigating conditions that may lower priority: |
| 42 | + - If the pattern is VERY unlikely |
| 43 | +- Soundness holes with real-world implications |
| 44 | + - Mitigating conditions that may lower priority: |
| 45 | + - Soundness holes that are difficult to trigger |
| 46 | + - Soundness holes that will not affect stable, e.g. if the hole makes use of a gated unstable feature. |
| 47 | +- Diagnostic regressions where the diagnostic is very common and the situation very confusing |
| 48 | +- ICEs for common scenarios or code patterns |
| 49 | + - Mitigating conditions that may lower priority: |
| 50 | + - If the code that triggers the ICE also triggers compilation errors, and those errors are emitted before the ICE |
| 51 | + - If the code in question makes use of unstable features, particularly if the ICE requires a feature gate |
| 52 | + |
| 53 | +A P-critical issue will receive the most attention. It must be assigned one or several people as soon as possible, and the rest of the team should do their best to help them out if/when applicable. |
| 54 | + |
| 55 | +## P-high |
| 56 | + |
| 57 | +`P-high` issues are issues that need attention from the compiler team, but not to the point that they need to be discussed at every meeting. |
| 58 | +They can be `P-critical` issues that have a mitigating condition as defined above, or important issues that aren't deemed blockers. |
| 59 | + |
| 60 | +Because there are too many `P-high` issues to fit in every compiler meeting, they should rather be handled asynchronously by the Prioritization WG, in order to help them move forward. They can still occasionally be brought up at meetings when it is deemed necessary. |
| 61 | + |
| 62 | +The effectiveness of the Prioritization WG will be a direct consequence of our ability to draw the line between `P-critical` and `P-high` issues. There shouldn't be too many `P-critical` issues that compiler meetings become unmanageable, but critical issues shouldn't get lost in the list of P-high issues. |
| 63 | + |
| 64 | +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. |
| 65 | + |
| 66 | +## P-medium and P-low |
| 67 | + |
| 68 | +`P-medium` refer to issues that aren't a priority for the team, and that will be resolved in the long run. Eg issues that will be fixed after a specific feature has landed. |
| 69 | +They are issues we would mentor someone interested in fixing. |
| 70 | +They will remain in this state until someone complains, a community member fixes it, or it gets fixed by accident. |
| 71 | + |
| 72 | + |
| 73 | +`P-low` refer to issues issue that the compiler team doesn't plan to resolve, but are still worth fixing. |
0 commit comments