From b14cf1dc301187a29bcc5766f5201104efecde32 Mon Sep 17 00:00:00 2001 From: Bryan Morgan Date: Wed, 14 Jan 2026 16:55:19 -0500 Subject: [PATCH] chore(automation): improve scheduled issue triage discovery and throughput (#16652) --- .../gemini-scheduled-issue-triage.yml | 135 ++++++++---------- 1 file changed, 63 insertions(+), 72 deletions(-) diff --git a/.github/workflows/gemini-scheduled-issue-triage.yml b/.github/workflows/gemini-scheduled-issue-triage.yml index 6aaeb950cf..7a966d59aa 100644 --- a/.github/workflows/gemini-scheduled-issue-triage.yml +++ b/.github/workflows/gemini-scheduled-issue-triage.yml @@ -59,22 +59,26 @@ jobs: run: |- set -euo pipefail - echo '🔍 Finding issues without labels...' - NO_LABEL_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \ - --search 'is:open is:issue no:label' --limit 10 --json number,title,body)" + echo '🔍 Finding issues missing area labels...' + NO_AREA_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \ + --search 'is:open is:issue -label:area/core -label:area/agent -label:area/enterprise -label:area/non-interactive -label:area/security -label:area/platform -label:area/extensions -label:area/unknown' --limit 100 --json number,title,body)" - echo '🏷️ Finding issues that need triage...' - NEED_TRIAGE_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \ - --search "is:open is:issue label:\"status/need-triage\"" --limit 10 --json number,title,body)" + echo '🔍 Finding issues missing kind labels...' + NO_KIND_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \ + --search 'is:open is:issue -label:kind/bug -label:kind/enhancement -label:kind/customer-issue -label:kind/question' --limit 100 --json number,title,body)" + + echo '🏷️ Finding issues missing priority labels...' + NO_PRIORITY_ISSUES="$(gh issue list --repo "${GITHUB_REPOSITORY}" \ + --search 'is:open is:issue -label:priority/p0 -label:priority/p1 -label:priority/p2 -label:priority/p3 -label:priority/unknown' --limit 100 --json number,title,body)" echo '🔄 Merging and deduplicating issues...' - ISSUES="$(echo "${NO_LABEL_ISSUES}" "${NEED_TRIAGE_ISSUES}" | jq -c -s 'add | unique_by(.number)')" + ISSUES="$(echo "${NO_AREA_ISSUES}" "${NO_KIND_ISSUES}" "${NO_PRIORITY_ISSUES}" | jq -c -s 'add | unique_by(.number)')" echo '📝 Setting output for GitHub Actions...' echo "issues_to_triage=${ISSUES}" >> "${GITHUB_OUTPUT}" ISSUE_COUNT="$(echo "${ISSUES}" | jq 'length')" - echo "✅ Found ${ISSUE_COUNT} issues to triage! 🎯" + echo "✅ Found ${ISSUE_COUNT} unique issues to triage! 🎯" - name: 'Get Repository Labels' id: 'get_labels' @@ -133,38 +137,33 @@ jobs: 1. You are only able to use the echo command. Review the available labels in the environment variable: "${AVAILABLE_LABELS}". 2. Check environment variable for issues to triage: $ISSUES_TO_TRIAGE (JSON array of issues) 3. Review the issue title, body and any comments provided in the environment variables. - 4. Identify the most relevant labels from the existing labels, focusing on kind/* and priority/*. - 5. If the issue already has a kind/ label don't change it. And if the issue already has a priority/ label do not change it for example: - If an issue has kind/bug you will only add a priority/ label. - Instead if an issue has no labels, you could add one label of each kind. + 4. Identify the most relevant labels from the existing labels, specifically focusing on area/*, kind/* and priority/*. + 5. Label Policy: + - If the issue already has a kind/ label, do not change it. + - If the issue already has a priority/ label, do not change it. + - If the issue already has an area/ label, do not change it. + - If any of these are missing, select exactly ONE appropriate label for the missing category. 6. Identify other applicable labels based on the issue content, such as status/*, help wanted, good first issue, etc. - 7. For kind/* limit yourself to only the single most applicable label. - 8. Give me a single short explanation about why you are selecting each label in the process. - 9. Output a JSON array of objects, each containing the issue number + 7. Give me a single short explanation about why you are selecting each label in the process. + 8. Output a JSON array of objects, each containing the issue number and the labels to add and remove, along with an explanation. For example: ``` [ { "issue_number": 123, - "labels_to_add": ["kind/bug", "priority/p2"], + "labels_to_add": ["area/core", "kind/bug", "priority/p2"], "labels_to_remove": ["status/need-triage"], - "explanation": "This issue is a bug that needs to be addressed with medium priority." - }, - { - "issue_number": 456, - "labels_to_add": ["kind/enhancement"], - "labels_to_remove": [], - "explanation": "This issue is an enhancement request that could improve the user experience." + "explanation": "This issue is a UI bug that needs to be addressed with medium priority." } ] ``` If an issue cannot be classified, do not include it in the output array. - 10. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5 + 9. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5 - Anything more than 6 versions older than the most recent should add the status/need-retesting label - 11. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label and leave a comment politely requesting the relevant information, eg.. if repro steps are missing request for repro steps. if version information is missing request for version information into the explanation section below. + 10. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label and leave a comment politely requesting the relevant information, eg.. if repro steps are missing request for repro steps. if version information is missing request for version information into the explanation section below. - After identifying appropriate labels to an issue, add "status/need-triage" label to labels_to_remove in the output. - 12. If you think an issue might be a Priority/P0 do not apply the priority/p0 label. Instead apply a status/manual-triage label and include a note in your explanation. - 13. If you are uncertain and have not been able to apply one each of kind/ and priority/ , apply the status/manual-triage label. + 11. If you think an issue might be a Priority/P0 do not apply the priority/p0 label. Instead apply a status/manual-triage label and include a note in your explanation. + 12. If you are uncertain about a category, use the area/unknown, kind/question, or priority/unknown labels as appropriate. If you are extremely uncertain, apply the status/manual-triage label. ## Guidelines @@ -174,54 +173,46 @@ jobs: - Do not add comments or modify the issue content. - Do not remove the following labels maintainer, help wanted or good first issue. - Triage only the current issue. + - Identify only one area/ label. - Identify only one kind/ label (Do not apply kind/duplicate or kind/parent-issue) - - Identify all applicable priority/* labels based on the issue content. It's ok to have multiple of these. + - Identify only one priority/ label. - Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario. - Categorization Guidelines: - P0: Critical / Blocker - - A P0 bug is a catastrophic failure that demands immediate attention. - - To be a P0 it means almost all users are running into this issue and it is blocking users from being able to use the product. - - You would see this in the form of many comments from different developers on the bug. - - It represents a complete showstopper for a significant portion of users or for the development process itself. - Impact: - - Blocks development or testing for the entire team. - - Major security vulnerability that could compromise user data or system integrity. - - Causes data loss or corruption with no workaround. - - Crashes the application or makes a core feature completely unusable for all or most users in a production environment. Will it cause severe quality degration? - - Is it preventing contributors from contributing to the repository or is it a release blocker? - Qualifier: Is the main function of the software broken? - Example: The gemini auth login command fails with an unrecoverable error, preventing any user from authenticating and using the rest of the CLI. - P1: High - - A P1 bug is a serious issue that significantly degrades the user experience or impacts a core feature. - - While not a complete blocker, it's a major problem that needs a fast resolution. Feature requests are almost never P1. - - Once again this would be affecting many users. - - You would see this in the form of comments from different developers on the bug. - Impact: - - A core feature is broken or behaving incorrectly for a large number of users or large number of use cases. - - Review the bug details and comments to try figure out if this issue affects a large set of use cases or if it's a narrow set of use cases. - - Severe performance degradation making the application frustratingly slow. - - No straightforward workaround exists, or the workaround is difficult and non-obvious. - Qualifier: Is a key feature unusable or giving very wrong results? - Example: Gemini CLI enters a loop when making read-many-files tool call. I am unable to break out of the loop and gemini doesn't follow instructions subsequently. - P2: Medium - - A P2 bug is a moderately impactful issue. It's a noticeable problem but doesn't prevent the use of the software's main functionality. - Impact: - - Affects a non-critical feature or a smaller, specific subset of users. - - An inconvenient but functional workaround is available and easy to execute. - - Noticeable UI/UX problems that don't break functionality but look unprofessional (e.g., elements are misaligned or overlapping). - Qualifier: Is it an annoying but non-blocking problem? - Example: An error message is unclear or contains a typo, causing user confusion but not halting their workflow. - P3: Low - - A P3 bug is a minor, low-impact issue that is trivial or cosmetic. It has little to no effect on the overall functionality of the application. - Impact: - - Minor cosmetic issues like color inconsistencies, typos in documentation, or slight alignment problems on a non-critical page. - - An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users. - Qualifier: Is it a "nice-to-fix" issue? - Example: Spelling mistakes etc. + + Categorization Guidelines (Priority): + P0 - Urgent Blocking Issues: + - DO NOT APPLY THIS LABEL AUTOMATICALLY. Use status/manual-triage instead. + - Definition: Urgent, block a significant percentage of the user base, and prevent frequent use of the Gemini CLI. + - This includes core stability blockers (e.g., authentication failures, broken upgrades), critical crashes, and P0 security vulnerabilities. + - Impact: Blocks development or testing for the entire team; Major security vulnerability; Causes data loss or corruption with no workaround; Crashes the application or makes a core feature completely unusable for all or most users. + - Qualifier: Is the main function of the software broken? + P1 - High-Impact Issues: + - Definition: Affect a large number of users, blocking them from using parts of the Gemini CLI, or make the CLI frequently unusable even with workarounds available. + - Impact: A core feature is broken or behaving incorrectly for a large number of users or use cases; Severe performance degradation; No straightforward workaround exists. + - Qualifier: Is a key feature unusable or giving very wrong results? + P2 - Significant Issues: + - Definition: Affect some users significantly, such as preventing the use of certain features or authentication types. + - Can also be issues that many users complain about, causing annoyance or hindering daily use. + - Impact: Affects a non-critical feature or a smaller, specific subset of users; An inconvenient but functional workaround is available; Noticeable UI/UX problems that look unprofessional. + - Qualifier: Is it an annoying but non-blocking problem? + P3 - Low-Impact Issues: + - Definition: Typically usability issues that cause annoyance to a limited user base. + - Includes feature requests that could be addressed in the near future and may be suitable for community contributions. + - Impact: Minor cosmetic issues; An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users. + - Qualifier: Is it a "nice-to-fix" issue? + + Categorization Guidelines (Area): + area/agent: Core Agent, Tools, Memory, Sub-Agents, Hooks, Agent Quality + area/core: User Interface, OS Support, Core Functionality + area/enterprise: Telemetry, Policy, Quota / Licensing + area/extensions: Gemini CLI extensions capability + area/non-interactive: GitHub Actions, SDK, 3P Integrations, Shell Scripting, Command line automation + area/platform: Build infra, Release mgmt, Testing, Eval infra, Capacity, Quota mgmt + area/security: security related issues + Additional Context: - - If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue - - This product is designed to use different models eg.. using pro, downgrading to flash etc. - - When users report that they dont expect the model to change those would be categorized as feature requests. + - If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue. + - This product is designed to use different models eg.. using pro, downgrading to flash etc. + - When users report that they dont expect the model to change those would be categorized as feature requests. - name: 'Apply Labels to Issues' if: |-