github.com/abdfnx/gh-api@v0.0.0-20210414084727-f5432eec23b8/docs/triage.md (about)

     1  # Triage role
     2  
     3  As we get more issues and pull requests opened on the GitHub CLI, we've decided on a weekly rotation
     4  triage role. The initial expectation is that the person in the role for the week spends no more than
     5  2 hours a day on this work; we can refine that as needed.
     6  
     7  ## Expectations for incoming issues
     8  
     9  All incoming issues need either an **enhancement**, **bug**, or **docs** 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
    36  
    37  - can this be closed outright?
    38    - e.g. spam/junk
    39    - close without comment
    40  - do we not want to do it?
    41    - e.g. have already discussed not wanting to do or duplicate issue
    42    - comment and close
    43  - are we ok with outside contribution for this?
    44    - e.g. the task is relatively straightforward, but no people on our team have the bandwidth to take it on at the moment
    45    - ensure that the thread contains all the context necessary for someone new to pick this up
    46    - add `help wanted` label
    47    - consider adding `good first issue` label
    48  - do we want to do it?
    49    - comment acknowledging it
    50    - add `core` label
    51    - add to project TODO column if this is something that should ship soon
    52  - is it intriguing, but requires discussion?
    53    - label `needs-design` if design input is needed, ping
    54    - label `needs-investigation` if engineering research is required before action can be taken
    55  - does it need more info from the issue author?
    56    - ask the user for details
    57    - add `needs-user-input` label
    58  - is it a usage/support question?
    59    - offer some instructions/workaround and close
    60  
    61  ## Pull request triage flowchart
    62  
    63  - can it be closed outright?
    64    - e.g. spam/junk
    65    - close
    66  - do we not want to do it?
    67    - comment and close
    68  - is it intriguing, but requires discussion and there is no referenced issue?
    69    - request an issue
    70    - close
    71  - is it something we want to include?
    72    - add to `needs review` column
    73  
    74  ## Weekly PR audit
    75  
    76  In the interest of not letting our open PR list get out of hand (20+ total PRs _or_ multiple PRs
    77  over a few months old), try to audit open PRs each week with the goal of getting them merged and/or
    78  closed. It's likely too much work to deal with every PR, but even getting a few closer to done is
    79  helpful.
    80  
    81  For each PR, ask:
    82  
    83  - is this too stale (more than two months old or too many conflicts)? close with comment
    84  - is this really close but author is absent? push commits to finish, request review
    85  - is this waiting on triage? go through the PR triage flow
    86  
    87  ## Useful aliases
    88  
    89  This gist has some useful aliases for first responders:
    90  
    91  https://gist.github.com/vilmibm/ee6ed8a783e4fef5b69b2ed42d743b1a
    92  
    93  ## Examples
    94  
    95  We want our project to be a safe and encouraging open-source environment. Below are some examples
    96  of how to empathetically respond to or close an issue/PR:
    97  
    98  - [Closing a quality PR its scope is too large](https://github.com/cli/cli/pull/1161)
    99  - [Closing a stale PR](https://github.com/cli/cli/pull/557#issuecomment-639077269)
   100  - [Closing a PR that doesn't follow our CONTRIBUTING policy](https://github.com/cli/cli/pull/864)
   101  - [Responding to a bug report](https://github.com/desktop/desktop/issues/9195#issuecomment-592243129)
   102  - [Closing an issue that out of scope](https://github.com/cli/cli/issues/777#issuecomment-612926229)
   103  - [Closing an issue with a feature request](https://github.com/desktop/desktop/issues/9722#issuecomment-625461766)