@@ -23,7 +23,7 @@ as triaging work is highly parallelizable and easy to get started with.
23
23
When an issue is opened, it gets the ` needs-triage ` label. This ensures that every issue gets an initial
24
24
look and that no issue is ignored, or that when it is ignored, it is at least visibly ignored by still having the label.
25
25
26
- ` needs-triage ` is an initial checkpoint. The effort needed to get an issue past the label should be minimal .
26
+ ` needs-triage ` is an initial checkpoint. The effort needed to get an issue past the label should be small .
27
27
28
28
To do the initial triage and remove the ` needs-triage ` label, the following conditions should be fulfilled/considered.
29
29
It's okay if not all of these are always considered; treat it as a guideline, not a hard checklist. It is also not exhaustive.
@@ -33,15 +33,15 @@ It's okay if not all of these are always considered; treat it as a guideline, no
33
33
You can of course answer the question too :) (but make sure to mention that the user should go to URLO/Discord next time).
34
34
- Add appropriate labels ([ Labels] ( #labels ) )
35
35
- Specifically, ` T-* ` and ` C-* ` are the most relevant
36
- - If the issue contains no reproduction but needs one, ask for one and add the ` S-needs-repro ` label
37
- - The issue is the wrong place for some kinds of feature requests. Tell the author about it.
38
- - Library API requests should follow [ its processes] ( https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html ) .
36
+ - If the issue contains no reproduction but needs one (when in doubt, it needs one) , ask for one and add the ` S-needs-repro ` label
37
+ - The issue tracker is the wrong place for some kinds of feature requests. Tell the author about it.
38
+ - Standard library API requests should follow [ libs-api processes] ( https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html ) .
39
39
- Language changes should be redirected to [ IRLO] ( https://internals.rust-lang.org/ ) or Zulip (t-lang).
40
- - If the issue could benefit from bisecting the regression, add ` E-needs-bisection ` (or do the bisection yourself)
40
+ - If the issue could benefit from bisecting the regression (when in doubt, it can) , add ` E-needs-bisection ` (or do the bisection yourself)
41
41
- Does this issue require nightly? Add ` requires-nightly ` .
42
42
- Is the issue a regression? Apply the ` regression-untriaged ` label (or figure out what regression it is exactly)
43
43
- If you happen to know people who this issue is relevant to, ping them.
44
- - For example, write ` cc @ThatPerson ` if ` ThatPerson ` has been working a lot on the problematic feature recently
44
+ - For example, write ` cc @ThatPerson ` if ` ThatPerson ` has been working a lot on the feature in question recently.
45
45
- Does this issue require incomplete or internal features? Add ` requires-{incomplete,internal}-features ` .
46
46
47
47
For applying and removing labels, unprivileged users can use ** @rustbot ** to add or remove
@@ -70,7 +70,7 @@ Triaging them the same way as `needs-triage` is also useful.
70
70
71
71
There are many different labels that can be applied to issues.
72
72
73
- - ` needs-triage ` : signals that an issue is new and needs initial triage
73
+ - ` needs-triage ` : Signals that an issue is new and needs initial triage
74
74
- ` T-* ` : Specifies the team or teams that this issue is relevant to, for example compiler, types or libs
75
75
- ` WG-* ` : Specifies the working groups that this issue is relevant to, for example WG-debugging.
76
76
- ` C-* ` : Specifies the category of the label, for example a bug, tracking issue or discussion
0 commit comments