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
+33-18Lines changed: 33 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,34 +2,52 @@
2
2
3
3
As we get more issues and pull requests opened on the GitHub CLI, we've decided on a weekly rotation
4
4
triage role. The initial expectation is that the person in the role for the week spends no more than
5
-
1-2 hours a day on this work; we can refine that as needed. Below is a basic timeline for a typical
6
-
triage day.
5
+
2 hours a day on this work; we can refine that as needed.
7
6
8
-
1. Note the time
9
-
2. Open every new [issue](https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue)/[pr](https://github.com/cli/cli/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse) in a tab
10
-
3. Go through each one and look for things that should be closed outright (See the PR and Issue section below for more details.)
11
-
4. Go through again and look for issues that are worth keeping around, update each one with labels/pings
12
-
5. Go through again and look for PRs that solve a useful problem but lack obvious things like tests or passing builds; request changes on those
13
-
6. Mark any remaining PRs (i.e. ones that look worth merging with a cursory glance) as `community` PRs and move to Needs Review
14
-
7. Look for [issues](https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue) and [PRs](https://github.com/cli/cli/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+sort%3Aupdated-desc) updated in the last day and see if they need a response.
15
-
8. Check the clock at each step and just bail out when an hour passes
7
+
## Expectations for incoming issues
16
8
17
-
# Incoming issues
9
+
All incoming issues need either an **enhancement** or **bug** label.
10
+
11
+
To be considered triaged, **enhancement** issues require at least one of the following additional labels:
12
+
13
+
-**core**: work reserved for the core CLI team
14
+
-**help wanted**: work that we would accept contributions for
15
+
-**needs-design**: work that requires input from a UX designer before it can move forward
16
+
-**needs-investigation**: work that requires a mystery be solved by the core team before it can move forward
17
+
-**needs-user-input**: work that requires more information from the reporter before it can move forward
18
+
19
+
To be considered triaged, **bug** issues require a severity label: one of **p1**, **p2**, or **p3**
20
+
21
+
For a more detailed breakdown of **how** to triage an issue, see the _Issue triage flowchart_ below.
22
+
23
+
## Expectations for community pull requests
24
+
25
+
To be considered triaged, incoming pull requests should:
26
+
27
+
- be checked for a corresponding **help wanted** issue
28
+
- be checked for basic quality: are the builds passing? have tests been added?
29
+
- be checked for redundancy: is there already a PR dealing with this?
30
+
31
+
Once a pull request has been triaged, it should be moved to the **Needs Review** column of the project board.
32
+
33
+
For a more detailed breakdown of **how** to triage an issue, see the _PR triage flowchart_ below.
34
+
35
+
## Issue triage flowchart
18
36
19
37
- can this be closed outright?
20
38
- e.g. spam/junk
21
39
- close without comment
22
40
- do we not want to do it?
23
41
- e.g. have already discussed not wanting to do or duplicate issue
24
42
- comment and close
25
-
-do we want someone in the community to do it?
43
+
-are we ok with outside contribution for this?
26
44
- e.g. the task is relatively straightforward, but no people on our team have the bandwidth to take it on at the moment
27
45
- ensure that the thread contains all the context necessary for someone new to pick this up
28
46
- add `help wanted` label
29
47
- consider adding `good first issue` label
30
48
- do we want to do it?
31
49
- comment acknowledging it
32
-
-label appropriately
50
+
-add `core` label
33
51
- add to project TODO column if this is something that should ship soon
34
52
- is it intriguing, but requires discussion?
35
53
- label `needs-design` if design input is needed, ping
@@ -40,9 +58,7 @@ triage day.
40
58
- is it a usage/support question?
41
59
- offer some instructions/workaround and close
42
60
43
-
# Incoming PRs
44
-
45
-
just imagine a flowchart
61
+
## Pull request triage flowchart
46
62
47
63
- can it be closed outright?
48
64
- e.g. spam/junk
@@ -53,10 +69,9 @@ just imagine a flowchart
53
69
- request an issue
54
70
- close
55
71
- is it something we want to include?
56
-
- add `community` label
57
72
- add to `needs review` column
58
73
59
-
# Weekly PR audit
74
+
##Weekly PR audit
60
75
61
76
In the interest of not letting our open PR list get out of hand (20+ total PRs _or_ multiple PRs
62
77
over a few months old), try to audit open PRs each week with the goal of getting them merged and/or
0 commit comments