STACKITGit/cli
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
cli/docs/triage.md
Mislav Marohnić bd25dae5e0 Update triaging docs
2020-10-13 18:07:05 +02:00

4 KiB
Raw Blame History

Triage role

As we get more issues and pull requests opened on the GitHub CLI, we've decided on a weekly rotation triage role. The initial expectation is that the person in the role for the week spends no more than 1-2 hours a day on this work; we can refine that as needed. Below is a basic timeline for a typical triage day.

  1. Note the time
  2. Open every new issue/pr in a tab
  3. Go through each one and look for things that should be closed outright (See the PR and Issue section below for more details.)
  4. Go through again and look for issues that are worth keeping around, update each one with labels/pings
  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
  6. Mark any remaining PRs (i.e. ones that look worth merging with a cursory glance) as community PRs and move to Needs Review
  7. Look for issues and PRs updated in the last day and see if they need a response.
  8. Check the clock at each step and just bail out when an hour passes

Incoming issues

  • can this be closed outright?
    • e.g. spam/junk
    • close without comment
  • do we not want to do it?
    • e.g. have already discussed not wanting to do or duplicate issue
    • comment and close
  • do we want someone in the community to do it?
    • e.g. the task is relatively straightforward, but no people on our team have the bandwidth to take it on at the moment
    • ensure that the thread contains all the context necessary for someone new to pick this up
    • add help wanted label
    • consider adding good first issue label
  • do we want to do it?
    • comment acknowledging it
    • label appropriately
    • add to project TODO column if this is something that should ship soon
  • is it intriguing, but requires discussion?
    • label needs-design if design input is needed, ping
    • label needs-investigation if engineering research is required before action can be taken
  • does it need more info from the issue author?
    • ask the user for details
    • add needs-user-input label
  • is it a usage/support question?
    • offer some instructions/workaround and close

Incoming PRs

just imagine a flowchart

  • can it be closed outright?
    • e.g. spam/junk
    • close
  • do we not want to do it?
    • comment and close
  • is it intriguing, but requires discussion and there is no referenced issue?
    • request an issue
    • close
  • is it something we want to include?
    • add community label
    • add to needs review column

Weekly PR audit

In the interest of not letting our open PR list get out of hand (20+ total PRs or multiple PRs over a few months old), try to audit open PRs each week with the goal of getting them merged and/or closed. It's likely too much work to deal with every PR, but even getting a few closer to done is helpful.

For each PR, ask:

  • is this too stale (more than two months old or too many conflicts)? close with comment
  • is this really close but author is absent? push commits to finish, request review
  • is this waiting on triage? go through the PR triage flow

Examples

We want our project to be a safe and encouraging open-source environment. Below are some examples of how to empathetically respond to or close an issue/PR: