You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/triage.md
+37-13Lines changed: 37 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,10 +6,12 @@ As we get more issues and pull requests opened on the GitHub CLI, we've decided
6
6
7
7
Review and label [open issues missing either the `enhancement`, `bug`, or `docs` label](https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue+-label%3Abug%2Cenhancement%2Cdocs+) and the label(s) corresponding to the command space prefixed with `gh-`, such as `gh-pr` for the `gh pr` command set, or `gh-extension` for the `gh extension` command set.
8
8
9
-
Then, engage with the issue and community with the goal to remove the `needs-triage` label from the issue. The heuristics for triaging the different issue types are as follow:
9
+
The heuristics for triaging the different issue types are as follows:
10
10
11
11
### Bugs
12
12
13
+
For bugs, the FR should engage with the issue and community with the goal to remove the `needs-triage` label from the issue.
14
+
13
15
To be considered triaged, `bug` issues require the following:
14
16
15
17
- A severity label `p1`, `p2`, and `p3`
@@ -23,33 +25,55 @@ To be considered triaged, `bug` issues require the following:
23
25
|`p2`| Affects more than a few users but doesn't prevent core functions |
24
26
|`p3`| Affects a small number of users or is largely cosmetic |
25
27
26
-
### Enhancements
28
+
### Enhancements and Docs
29
+
30
+
For `enhancement` issues, the FR's role is to prepare the issue for team review and triage.
31
+
32
+
When a new issue is opened, the FR **should**:
27
33
28
-
To be considered triaged, `enhancement` issues require either
34
+
- Acknowledge the issue
35
+
- Assign themselves to the issue
36
+
- Ensure there is enough information to understand the enhancement's scope and value
37
+
- Ask the user for more information about value and use-case, if necessary
38
+
- Leave the `needs-triage` label on the issue
39
+
- Add the `needs-user-input` and `needs-investigation` labels as needed
29
40
30
-
- Clearly defined Acceptance Criteria as above
31
-
- The `needs-investigation` or `needs-design` label with a clearly defined set of open questions to be investigated.
41
+
When the FR has enough information to be triaged, they should:
42
+
- Remove the `needs-user-input` and `needs-investigation` labels
43
+
- Remove their assignment from the issue
32
44
33
-
### Docs
45
+
The FR should **avoid**:
34
46
35
-
To be considered triaged, `docs` issues require clearly defined Acceptance Criteria, as defined above
47
+
- Thoroughly investigating the enhancement's technical feasibility
48
+
- Prematurely accepting the enhancement request
49
+
- Removing the `needs-triage` label
50
+
- Labeling issues as `help wanted`
36
51
37
-
## Additional triaging processes and labels
52
+
## Additional triaging labels
38
53
39
-
Before removing the `needs-triage` label, consider adding any of the following labels below.
54
+
The FR can consider adding any of the following labels below.
40
55
41
56
| Label | Description |
42
57
| - | - |
43
58
|`discuss`| Some issues require discussion with the internal team. Adding this label will automatically open up an internal discussion with the team to facilitate this discussion. |
44
59
|`core`| Defines what we would like to do internally. We tend to lean towards `help wanted` by default, and adding `core` should be reserved for trickier issues or implementations we have strong opinions/preferences about. |
45
-
|`good first issue`| Used to denote when an issue may be a good candidate for a first-time contributor to the CLI. These are usually small and well defined issues. |
46
-
|`help wanted`| Defines what we feel the community could solve should they care to contribute, respectively. We tend to lean towards `help wanted` by default, and adding `core` should be reserved for trickier issues or implementations we have strong opinions/preferences about. |
47
-
|`invalid`| Added to spam and abusive issues. |
48
60
|`needs-user-input`| After asking any contributors for more information, add this label so it is clear that the issue has been responded to and we are waiting on the user. |
61
+
|`needs-investigation`| Used when the issue requires further investigation before it can be reviewed and triaged. This is often used for issues that are not clearly bugs or enhancements, or when the FR needs to gather more information before proceeding. |
62
+
|`invalid`| Added to spam and abusive issues. |
63
+
64
+
### Labels for team enhancement triaging
65
+
66
+
The FR should **avoid** adding these labels outside of team enhancement triage.
67
+
68
+
| Label | Description |
69
+
| - | - |
70
+
|`good first issue`| Used to denote when an issue may be a good candidate for a first-time contributor to the CLI. These are usually small and well defined issues. |
71
+
|`help wanted`| These issues are ready for community contribution. |
72
+
|`help wanted candidate`| Used to denote when an issue may be a good candidate for community contribution. Issues labelled this way are discussed internally and may be promoted to `help wanted`. |
49
73
50
74
## Expectations for community pull requests
51
75
52
-
All incoming pull requests are assigned to one of the engineers for review on a round-robin basis.
76
+
All incoming pull requests are assigned to one of the engineers for review on a load-balanced basis.
53
77
The person in a triage role for a week could take a glance at these pull requests, mostly to see whether
54
78
the changeset is feasible and to allow the associated CI run for new contributors.
- The PowerShell stop parse flag %[1]s--%[2]s%[1]s: <https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_parsing?view=powershell-7.5#the-stop-parsing-token>
44
+
- The Unix-like %[1]s--%[1]s argument: <https://www.gnu.org/software/bash/manual/bash.html#Shell-Builtin-Commands-1>
0 commit comments