DEV/flutter_flutter
1
0
Fork 0
mirror of https://github.com/flutter/flutter.git synced 2026-02-20 02:29:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge d4bdacd2b5e7c9090f1864d5af67e43c151a1148 into 06df71c51446e96939c6a615b7c34ce9123806ba

Browse Source
This commit is contained in:
stuartmorgan-g 2026-02-19 14:16:17 -03:00 committed by GitHub
commit 6a6c63e406
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 30 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
docs/triage/README.md
View File

@ -1,3 +1,11 @@
# Triage Overview
Issues generally go through two triage steps:
- Primary triage ensures that the bug is clear and actionable, then routes it to a team for secondary triage. This usually happens within 1–2 working days.
- Secondary triage by the relevant team determines a priority, and may add more labels and information. This usually happens once per week.
PRs are triaged directly by teams during secondary triage, and assigned reviewers. This usually happens once per week.
# Primary issue triage process
The process of triaging new incoming bugs consists of processing the list of [issues without team-* labels, with no assignees, and not labeled `will need additional triage`](https://github.com/flutter/flutter/issues?q=is%3Aissue%20is%3Aopen%20no%3Aassignee%20-label%3A%22will%20need%20additional%20triage%22%20-label%3Ateam-devexp%2Cteam-accessibility%2Cteam-codelabs%2Cteam-ecosystem%2Cteam-infra%2Cteam-engine%2Cteam-framework%2Cteam-ios%2Cteam-tool%2Cteam-web%2Cteam-linux%2Cteam-macos%2Cteam-windows%2Cteam-design%2Cteam-android%2Cteam-text-input) as described in this section, so as to make that list empty.
@ -38,18 +46,24 @@ As discussed above, if a filed issue is unactionable due to vagueness or a lack
In the specific case of a bug with unclear steps to reproduce but very specific symptoms, we like to leave the issue open so that other people having the same problem can congregate together and maybe together we can figure out the underlying cause. This only applies to issues that have very specific symptoms like a specific and unusual crash signature, a specific and unusual error message, or other unusual and recognizable symptoms, and where some effort was made on the part of the bug reporter to determine the cause (even if that effort was ultimately futile).
### Duplicates
#### Duplicates
If you recognize that this bug is a duplicate of an existing bug, add a reference to that bug in a comment, then close the bug. Skip the remaining steps. As you triage more and more bugs you will become more and more familiar with the existing bugs and so you will get better and better at marking duplicates in this way.
If you recognize that this bug is a duplicate of an existing bug, add a reference to that bug in a comment, close the bug using the "Close as duplicate" option, and add `r: duplicate`. Skip the remaining steps. As you triage more and more bugs you will become more and more familiar with the existing bugs and so you will get better and better at marking duplicates in this way.
When closing the duplicate bug, the GitHub issue tracker does not copy the list of people being notified on the closed bug into the original bug. This can matter, especially when asking on the original bug for things like reproduction steps. Consider cc'ing the author of the duplicate issue into the original issue, especially if we're still trying to determine reproduction steps for the issue.
### Requests for help (documentation issues)
#### Requests for help (documentation issues)
If the bug report is a question, then it probably belongs in Stack Overflow or on our #help channel or some other forum for getting help. However, if it appears that the reporter did try to read our documentation to find the answer, and failed, or, if you look in our documentation and find it is inadequate here, then please consider it a documentation bug (and update the summary accordingly).
If you are confident our official documentation (on flutter.dev or api.flutter.dev) fully answers their question, then provide a link to the relevant page and close the issue, being very polite and asking them to reopen if the documentation is not sufficiently clear for them.
When closing an issue because it is a help request rather than an actionable issue, mark it `r: invalid`.
#### Issues in other products.
If an issue is in a product that is not part of the Flutter project, such as a third-party package, close the issue with a comment suggesting that the reporter file the issue with the authors of that product, and add `r: invalid`. However, if there's a reason to believe that an issue involving a third-party product is *caused* by Flutter (for exmaple, a tool or engine change that unexpectedly breaks a third-party plugin), don't close it, and triage it based on the potential Flutter cause.
### Labels
**General rule: The more labels an issue has, the better!** _See also: [List of labels](https://github.com/flutter/flutter/labels)_
@ -71,15 +85,15 @@ In general the flow chart for team assignment is as follows, stopping as soon as
- If it's about the release process or tooling (e.g., `packages_autoroller`), add `team-infra` and `infra: release`.
- If it's about the Flutter team's CI or infrastructure, add `team-infra`.
- If it's about Impeller, add `team-engine`.
- If it's about accessibility (e.g. `Semantics`, `talkBack`, `voiceOver`), add `team-accessibility`.
- If it's specific to a single platform, also add that platform's fyi label.
- If it's about accessibility (e.g. `Semantics`, `talkBack`, `voiceOver`), add `team-accessibility`. And:
- if it's specific to a single platform, also add that platform's `fyi-*` label.
- If it's about Cupertino or Material Design, add `team-design`.
- If it's about text fields or other user-facing text field, text input, or text selection issues, add `team-text-input`.
- If it's specific to a single platform, also add that platform's fyi label.
- If it's specific to text fields or text input, also add `a: text input`.
- If it's specific to text selection or selectable region also add `f: selection`.
- If it's specific to a single platform, add that platform's team (`team-android`, `team-ios`, `team-linux`, `team-macos`, `team-web`, or `team-windows`).
- If the issue is about a first-party package, also add `fyi-ecosystem`.
- If it's about text fields or other user-facing text field, text input, or text selection issues, add `team-text-input`. And:
- if it's specific to a single platform, also add that platform's `fyi-*` label.
- if it's specific to text fields or text input, also add `a: text input`.
- if it's specific to text selection or selectable region also add `f: selection`.
- If it's specific to a single platform, add that platform's team (`team-android`, `team-ios`, `team-linux`, `team-macos`, `team-web`, or `team-windows`). And:
- if the issue is about a first-party package, also add `fyi-ecosystem`.
- If it's about the Flutter engine, add `team-engine`.
- If it's about the Flutter framework, add `team-framework`.
- If it's about the Flutter tool, add `team-tool`.
@ -111,9 +125,11 @@ Bugs relating to the website should be moved to the `flutter/website` repo.
Once the main labels above are added, consider what additional labels could be added, in particular:
Add any of the applicable "c: *" labels; typically only one will apply but sometimes `c: regression` will apply in conjunction with one of the others.
Add any of the applicable "a: *" labels. There are many, it's worth browsing the list to get an idea of which ones might apply.
- Most issues will have a general category label, such as `engine`, `framework`, `tool`, or `package`. An issue with a category-specific label (`e: *` for engine, `f: *` for framework, `t: *` for tool, `p: *` for package) should have the associated category label.
- Add any of the applicable `c: *` labels; typically only one will apply but sometimes `c: regression` will apply in conjunction with one of the others.
- Add any of the applicable `a: *` labels. There are many, it's worth browsing the list to get an idea of which ones might apply.
- If an issue is specific to one or more platforms, add the corresponding `platform-*` label(s). However, don't add platform labels if the issue applies to every relevant platform (e.g., all platforms that a plugin supports).
- If a `platform-web` issue is specific to one or more browsers, add the corresponding `browser: *` label(s). As with `platform-*`, only do this when it's known to happen on some browsers but not others.
### Additional comments