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 2 hours a day on this work; we can refine that as needed.
Review and label open issues missing either the enhancement, bug, or docs label.
Any issue that is accepted to be done as either an enhancement, bug, or docs requires explicit Acceptance Criteria in a comment on the issue before needs-triage label is removed.
To be considered triaged, enhancement issues require at least one of the following additional labels:
core: reserved for the core CLI teamhelp wanted: signal that we are accepting contributions for thisdiscuss: add to our team's queue to discuss during a syncneeds-investigation: work that requires a mystery be solved by the core team before it can move forwardneeds-user-input: we need more information from our users before the task can move forward
To be considered triaged, bug issues require a severity label: one of p1, p2, or p3, which are defined as follows:
p1: Affects a large population and inhibits workp2: Affects more than a few users but doesn't prevent core functionsp3: Affects a small number of users or is largely cosmetic
All incoming pull requests are assigned to one of the engineers for review on a round-robin basis. The person in a triage role for a week could take a glance at these pull requests, mostly to see whether the changeset is feasible and to allow the associated CI run for new contributors.
- can this be closed outright?
- e.g. spam/junk
- add the
invalidlabel - close without comment
- do we not want to do it?
- e.g. we have already discussed not wanting to do or it's a duplicate issue
- add the appropriate label (e.g.
duplicate) - comment and close
- do we want external contribution for this?
- e.g. the task is relatively straightforward, but the core team does not have the bandwidth to take it on
- ensure that the thread contains all the context necessary for someone new to pick this up
- add the
help wantedlabel - consider adding
good first issuelabel
- do we want external design contribution for this?
- e.g. the task is worthwhile, but needs design work to flesh out the details before implementation and the core team does not have the bandwidth to take it on
- ensure that the thread contains all the context necessary for someone new to pick this up
- add both the
help wantedandneeds-designlabels
- do we want to do it?
- add the
corelabel - comment acknowledging that
- add the
- is it intriguing, but requires discussion?
- Add the
discusslabel - Add the
needs-investigationlabel if engineering research is required before action can be taken
- Add the
- does it need more info from the issue author?
- ask the user for details
- add the
needs-user-inputlabel
- is it a usage/support question?
- Convert the Issue to a Discussion
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
This gist has some useful aliases for first responders:
https://gist.github.com/vilmibm/ee6ed8a783e4fef5b69b2ed42d743b1a
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: