Update issue triage guidelines and label usage #11454
Conversation
Clarifies the triage process for bugs, enhancements, and docs issues, including the responsibilities of the first responder (FR). Expands and reorganizes label definitions, adds new labels for investigation and team triage, and updates the pull request assignment process to be load balanced. Improves instructions for engaging with issues and managing labels.
There was a problem hiding this comment.
Pull Request Overview
This PR updates the issue triage documentation to clarify responsibilities and improve the triage process. The changes focus on defining the First Responder (FR) role more clearly and reorganizing the label system for better workflow management.
Key changes:
- Clarifies FR responsibilities for different issue types (bugs vs enhancements/docs)
- Adds new labels for investigation and team triage workflows
- Updates pull request assignment from round-robin to load balanced
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
mxie
left a comment
There was a problem hiding this comment.
Seems aligned what the changes we agreed on. 👍
andyfeller
left a comment
There was a problem hiding this comment.
Makes sense, no blocking comments but some additional questions for later potential updates
| The FR should **avoid**: | ||
|
|
||
| To be considered triaged, `docs` issues require clearly defined Acceptance Criteria, as defined above | ||
| - Thoroughly investigating the enhancement's technical feasibility |
There was a problem hiding this comment.
question: do you expect FR to provide any feasibility feedback in triaging issues?
I trust this guidance is to avoid FR sinking significant time into triaging new issues as much of this investigation is part of doing the work. The operative word "thoroughly" is the unclear part of this line.
There was a problem hiding this comment.
@andyfeller I think the spirit of the experiment is to do little to no feasibility investigations, leaving feasibility conversations until after we decide we want the feature in the first place.
I think some light 2-5 minute poking around code & dependencies is fine, if someone is hellbent on doing so, and I expect I'll find myself doing that sometimes too. The spirit of the experiment is to avoid spending time reaching conclusions about the feasibility.
There's going to be times where you might know, with a 5 minute investigation, that you could immediately reject an enhancement because it's not technically feasible. I still want people to be empowered to do that, but I want to avoid the time sink that typically comes along with that investigation.
I'd much rather the FR spend more time thinking "what questions do I need to ask to ensure the team has a complete picture of why this user wants this and what the value is". I think asking these questions is much more in line with the spirit of the experiment.
There was a problem hiding this comment.
My take is it's the FR responsibility to rule out infeasible requests. Note that in the sync meeting we don't want go deep or we lose the time.
There was a problem hiding this comment.
@babakks I think there's some confusion in that feasibility investigation shouldn't be done in the enhancement triage either. Deep feasibility work should be a spike, if needed, after we've decided we want to accept a feature and either want to shape it for help wanted or shape it for ourselves (core). Otherwise we may spend time researching the feasibility of a feature that has no value and the team doesn't want anyways! :(
If you could consider these as gates, I want issues to first pass a value and impact gate, then a feasibility gate, then the final implementation gate. The experiment proposes that the FR and enhancement triage sync together make up the value and impact gate.
Like I said though, some light feasibility investigation is bound to happen, but I think we should be ruthlessly timeboxing it.
Examples of what I consider light feasibility work:
- Checking if a dependency supports xyz
- Reviewing technical conflicts that would make xyz clearly and obviously not feasible
Examples of what I consider deep feasibility work:
- Analysis of what codepaths would need to change
- Analysis of different implementation options
- Spiking work / writing any code at all
- Complete design proposals
- Discussion with maintainers of xyz dependency to see if they could support xyz
There was a problem hiding this comment.
Definitely, time boxing should be the rule. I think we're mostly aligned on this now.
| - Labeling issues as `help wanted` | ||
|
|
||
| ## Additional triaging processes and labels | ||
| ## Additional triaging labels |
There was a problem hiding this comment.
question: should suspect-spam label be mentioned in this doc anywhere?
There was a problem hiding this comment.
Yes, but that's a different topic, so let's handle that in a follow up PR please :)
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [cli/cli](https://github.com/cli/cli) | minor | `v2.76.2` -> `v2.78.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>cli/cli (cli/cli)</summary> ### [`v2.78.0`](https://github.com/cli/cli/releases/tag/v2.78.0): GitHub CLI 2.78.0 [Compare Source](cli/cli@v2.77.0...v2.78.0) #### ℹ️ Note This release was cut primarily to resolve a Linux package distribution issue. We recommend reviewing [the v2.77.0 release notes](https://github.com/cli/cli/releases/tag/v2.77.0) for the complete set of latest features and fixes. #### What's Changed ##### ✨ Features - Add `--force` flag to `gh run cancel` by [@​ankddev](https://github.com/ankddev) in [#​11513](cli/cli#11513) ##### 🐛 Fixes - Fix failing to release Linux packages (affected v2.77.0). See [v2.77.0](https://github.com/cli/cli/releases/tag/v2.77.0) for more information. **Full Changelog**: <cli/cli@v2.77.0...v2.78.0> ### [`v2.77.0`](https://github.com/cli/cli/releases/tag/v2.77.0): GitHub CLI 2.77.0 [Compare Source](cli/cli@v2.76.2...v2.77.0) ####⚠️ Incomplete Release The v2.77.0 release experienced a failure publishing to our official Linux repos. This is resolved in [v2.78.0](https://github.com/cli/cli/releases/tag/v2.78.0), so we recommend using that release instead. #### What's Changed ##### ✨ Features - Report that v1 classic projects are detected on GHES 3.16.x or older by [@​andyfeller](https://github.com/andyfeller) in [#​11491](cli/cli#11491) - Display v2 projects in `gh issue view` by [@​andyfeller](https://github.com/andyfeller) in [#​11496](cli/cli#11496) - View v2 projects in `gh pr view` output by [@​andyfeller](https://github.com/andyfeller) in [#​11497](cli/cli#11497) - Ensure users can see v2 projects when viewing issues and MRs, avoid v1 projects on GHES 3.17 and newer by [@​andyfeller](https://github.com/andyfeller) in [#​11514](cli/cli#11514) ##### 🐛 Fixes - fix error for ErrReleaseNotFound when fetching ref by [@​ejahnGithub](https://github.com/ejahnGithub) in [#​11451](cli/cli#11451) - add test for FetchRefSHA by [@​ejahnGithub](https://github.com/ejahnGithub) in [#​11481](cli/cli#11481) - Fix `gh repo delete --yes` safety issue when no repository argument provided by [@​Copilot](https://github.com/Copilot) in [#​11536](cli/cli#11536) ##### 📚 Docs & Chores - Improve spam detection evals by [@​babakks](https://github.com/babakks) in [#​11419](cli/cli#11419) - Fix `help wanted` label regexp in CI automation by [@​babakks](https://github.com/babakks) in [#​11423](cli/cli#11423) - Update spam detection to comment on and close issue by [@​andyfeller](https://github.com/andyfeller) in [#​11435](cli/cli#11435) - Adding a note to `gh search` docs to explain the usage of `--` to exclude certain results by [@​Sukhpreet-s](https://github.com/Sukhpreet-s) in [#​11162](cli/cli#11162) - Update issue triage guidelines and label usage by [@​BagToad](https://github.com/BagToad) in [#​11454](cli/cli#11454) - Reorganize installation docs by [@​andyfeller](https://github.com/andyfeller) in [#​11473](cli/cli#11473) - Update govulncheck workflow to scan source code by [@​BagToad](https://github.com/BagToad) in [#​11482](cli/cli#11482) - Hidden trusted root flag for release verify by [@​ejahnGithub](https://github.com/ejahnGithub) in [#​11511](cli/cli#11511) #####Dependencies - Regenerate third-party licenses on trunk pushes by [@​andyfeller](https://github.com/andyfeller) in [#​11370](cli/cli#11370) - Update third-party license versions by [@​BagToad](https://github.com/BagToad) in [#​11557](cli/cli#11557) - Bump Go to 1.24.6 by [@​github-actions](https://github.com/github-actions)\[bot] in [#​11467](cli/cli#11467) - chore(deps): bump github.com/spf13/pflag from 1.0.6 to 1.0.7 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11319](cli/cli#11319) - chore(deps): bump actions/download-artifact from 4 to 5 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11458](cli/cli#11458) - chore(deps): bump actions/checkout from 4 to 5 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11490](cli/cli#11490) - chore(deps): bump github.com/yuin/goldmark from 1.7.12 to 1.7.13 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11368](cli/cli#11368) - Bump google.golang.org/grpc & other required dependencies by [@​BagToad](https://github.com/BagToad) in [#​11510](cli/cli#11510) - chore(deps): bump google.golang.org/grpc from 1.73.0 to 1.74.2 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11367](cli/cli#11367) - chore(deps): bump github.com/cli/go-gh/v2 from 2.12.1 to 2.12.2 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11537](cli/cli#11537) - chore(deps): bump github.com/go-viper/mapstructure/v2 from 2.3.0 to 2.4.0 by [@​dependabot](https://github.com/dependabot)\[bot] in [#​11556](cli/cli#11556) #### New Contributors - [@​Sukhpreet-s](https://github.com/Sukhpreet-s) made their first contribution in [#​11162](cli/cli#11162) - [@​Copilot](https://github.com/Copilot) made their first contribution in [#​11536](cli/cli#11536) **Full Changelog**: <cli/cli@v2.76.2...v2.77.0> </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS44Mi4xIiwidXBkYXRlZEluVmVyIjoiNDEuODIuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
Clarifies the triage process for bugs, enhancements, and docs issues, including the responsibilities of the first responder (FR). Expands and reorganizes label definitions, adds new labels for investigation and team triage, and updates the pull request assignment process to be load balanced. Improves instructions for engaging with issues and managing labels.