opensource/galaxy
3
0
Fork 0
mirror of https://github.com/galaxyproject/galaxy.git synced 2026-08-29 02:26:59 +08:00
Code Issues Packages Projects Releases Wiki Activity

Skip assigned issues in weekly triage, use complexity instead of time estimates

Browse Source
This commit is contained in:
Dannon Baker
2026-03-03 13:43:29 -05:00
parent ee787cc695
commit 48c536aaad
3 changed files with 45 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/commands/triage-bug.md
+18 -15
View File
@@ -1,17 +1,19 @@
Persona: You are a senior engineer responsible for maintaining the Galaxy project.
Arguments:
- $ARGUMENTS - Github issue number and optional work level (low/medium/high, default: medium)
Examples: "21536", "21536 low", "21536 high"
Parse the issue number and work level from $ARGUMENTS. Work levels control triage depth:
- **low**: Research and understand only, skip fix planning
- **medium**: Research + single plan for most probable cause
- **high**: Research + plans for all theories + plan assessment
You will be supplied a Github issue number to triage. A Galaxy developer will be assigned the issue but your job is to structure the conversation around the issue.
Fetch the issue using "gh issue view <number>" and write the issue contents to ``ISSUE_<#>.md``.
Fetch the issue using "gh issue view <number>" and write the issue contents to `ISSUE_<#>.md`.
Write all triage artifacts to the current working directory.
@@ -22,30 +24,31 @@ Launch subagents to perform actions to help in the triage process. Run independe
When to launch subagents and what they should do are as follows:
- When: Always (all levels)
What: Launch a subagent to research the issue. This subagent should create a document called ``ISSUE_<#>_CODE_RESEARCH.md`` where ``<#>`` is the issue number. The subagent should attempt to find the source issue, summarize the code relevant issue, file paths, and develop (roughly 1-3) theories about the possible true cause of the issue.
What: Launch a subagent to research the issue. This subagent should create a document called `ISSUE_<#>_CODE_RESEARCH.md` where `<#>` is the issue number. The subagent should attempt to find the source issue, summarize the code relevant issue, file paths, and develop (roughly 1-3) theories about the possible true cause of the issue.
- When: The issue is complex and if the issue seems like a regression (all levels)
What: Launch a subagent to read in the "code research" document and develop theories about when the issue was introduced. Create a document called ``ISSUE_<#>_HISTORY.md`` where ``<#>`` is the issue number. This document should include links to pull requests that are relevant, authors that have touched the code, etc...
What: Launch a subagent to read in the "code research" document and develop theories about when the issue was introduced. Create a document called `ISSUE_<#>_HISTORY.md` where `<#>` is the issue number. This document should include links to pull requests that are relevant, authors that have touched the code, etc...
- When: Work level is **medium** - create ONE plan for the most probable cause
What: Launch a subagent to come up with a detailed plan to fix the issue with the most probable root cause identified in the code research. Create a document called ``ISSUE_<#>_PLAN.md``.
What: Launch a subagent to come up with a detailed plan to fix the issue with the most probable root cause identified in the code research. Create a document called `ISSUE_<#>_PLAN.md`.
- When: Work level is **high** - create a plan for EACH cause identified
What: Launch a subagent for each true cause identified to come up with a detailed plan to fix the issue with the assumed root cause. Create a document called ``ISSUE_<#>_PLAN_<cause>.md`` where cause is a short description of the cause of issue distinguishing it from the other root causes.
What: Launch a subagent for each true cause identified to come up with a detailed plan to fix the issue with the assumed root cause. Create a document called `ISSUE_<#>_PLAN_<cause>.md` where cause is a short description of the cause of issue distinguishing it from the other root causes.
- When: Work level is **high** only
What: Launch a subagent to read the code research and the relevant plans to address the issue. This subagent should evaluate the quality of the plans and assess the probability of each to solve the problem. This subagent should create a document called ``ISSUE_<#>_PLAN_ASSESSMENT.md``.
What: Launch a subagent to read the code research and the relevant plans to address the issue. This subagent should evaluate the quality of the plans and assess the probability of each to solve the problem. This subagent should create a document called `ISSUE_<#>_PLAN_ASSESSMENT.md`.
- When: Always (all levels)
What: Launch a subagent to assess bug importance. Create a document called ``ISSUE_<#>_IMPORTANCE.md``. Assess:
- Severity (critical/high/medium/low): data loss/security > crash/hang > functional breakage > cosmetic/minor
- Blast radius: all users, specific configurations, edge cases only
- Workaround existence: none / painful / acceptable
- Regression status: new regression (which version) vs long-standing
- User impact signals: issue reactions, duplicate reports, support requests
- Recommendation: hotfix / next release / backlog / wontfix with rationale
What: Launch a subagent to assess bug importance. Create a document called `ISSUE_<#>_IMPORTANCE.md`. Assess:
- Severity (critical/high/medium/low): data loss/security > crash/hang > functional breakage > cosmetic/minor
- Blast radius: all users, specific configurations, edge cases only
- Workaround existence: none / painful / acceptable
- Regression status: new regression (which version) vs long-standing
- User impact signals: issue reactions, duplicate reports, support requests
- Recommendation: hotfix / next release / backlog / wontfix with rationale
Once all of the subagents are done - please write a new document called ``ISSUE_<#>_SUMMARY.md``.
Once all of the subagents are done - please write a new document called `ISSUE_<#>_SUMMARY.md`.
This document should contain:
- A concise one paragraph top-line summary about the issue that we will use to guide the discussion about the issue. Including the most probable fix and most probable true cause (with source of the regression if you've collected an issue history document).
- Importance assessment summary: severity, blast radius, regression status, and overall priority recommendation.
- Any relevant questions about the context around the issue that would be helpful in debugging and guiding the discussion as a large group.
- An estimate on the effort required to fix the issue, an assessment on how difficult it is to recreate and test the issue.
- A complexity assessment (low/medium/high) for the fix, and how difficult it is to recreate and test the issue.
Publish all the relevant documents to a gist and print a comment to the user that they can post to the Github issue to aid with the triage process and offer to copy that comment to the clipboard. The comment should be concise but should include all relevant data and questions from the summary document.
.claude/commands/triage-feature.md
+16 -13
View File
@@ -1,17 +1,19 @@
Persona: You are a senior engineer responsible for maintaining the Galaxy project.
Arguments:
- $ARGUMENTS - Github issue number and optional work level (low/medium/high, default: medium)
Examples: "21474", "21474 low", "21474 high"
Parse the issue number and work level from $ARGUMENTS. Work levels control triage depth:
- **low**: Research and understand only, skip implementation planning
- **medium**: Research + single recommended approach with focused plan
- **high**: Research + multiple approaches + comprehensive plan
You will be supplied a Github issue number for a feature request to triage. A Galaxy developer will be assigned the issue but your job is to structure the conversation around the feature.
Fetch the issue using "gh issue view <number>" and write the issue contents to ``FEATURE_<#>.md``.
Fetch the issue using "gh issue view <number>" and write the issue contents to `FEATURE_<#>.md`.
Write all triage artifacts to the current working directory.
@@ -20,26 +22,27 @@ Launch subagents to perform actions to help in the triage process. Run independe
When to launch subagents and what they should do are as follows:
- When: Always (all levels)
What: Launch a subagent to research user demand signals. This subagent should create a document called ``FEATURE_<#>_DEMAND.md``. The subagent should analyze: issue reactions/thumbs up, linked/duplicate issues, comment frequency and sentiment, any related discussion threads. Quantify demand where possible.
What: Launch a subagent to research user demand signals. This subagent should create a document called `FEATURE_<#>_DEMAND.md`. The subagent should analyze: issue reactions/thumbs up, linked/duplicate issues, comment frequency and sentiment, any related discussion threads. Quantify demand where possible.
- When: Always (all levels)
What: Launch a subagent to research the codebase for related functionality. This subagent should create a document called ``FEATURE_<#>_CODE_RESEARCH.md``. The subagent should find: existing similar features, relevant extension points, architectural patterns to follow, and files/modules that would need modification.
What: Launch a subagent to research the codebase for related functionality. This subagent should create a document called `FEATURE_<#>_CODE_RESEARCH.md`. The subagent should find: existing similar features, relevant extension points, architectural patterns to follow, and files/modules that would need modification.
- When: Work level is **high** and the feature has multiple possible implementation approaches
What: Launch a subagent to develop alternative implementation approaches. Create a document called ``FEATURE_<#>_APPROACHES.md``. This document should outline 2-4 approaches with tradeoffs (complexity, breaking changes, performance, maintainability).
What: Launch a subagent to develop alternative implementation approaches. Create a document called `FEATURE_<#>_APPROACHES.md`. This document should outline 2-4 approaches with tradeoffs (complexity, breaking changes, performance, maintainability).
- When: Always (all levels)
What: Launch a subagent to assess importance. Create a document called ``FEATURE_<#>_IMPORTANCE.md``. Assess:
- User demand (high/medium/low) based on reactions, comments, linked issues
- Strategic value (high/medium/low) - does it align with project direction, enable other features, improve UX significantly
- Effort estimate (small/medium/large/xlarge) based on code research
- Risk assessment (breaking changes, migration needs, security considerations)
- Recommendation: prioritize now / backlog / defer / decline with rationale
What: Launch a subagent to assess importance. Create a document called `FEATURE_<#>_IMPORTANCE.md`. Assess:
- User demand (high/medium/low) based on reactions, comments, linked issues
- Strategic value (high/medium/low) - does it align with project direction, enable other features, improve UX significantly
- Complexity (low/medium/high) based on code research — do not estimate time or duration
- Risk assessment (breaking changes, migration needs, security considerations)
- Recommendation: prioritize now / backlog / defer / decline with rationale
- When: Work level is **medium** - create a focused implementation plan
What: Launch a subagent to read the research documents and create an implementation plan for the single recommended approach. Create a document called ``FEATURE_<#>_PLAN.md``. Include: recommended approach, affected files, testing strategy, migration considerations if any.
What: Launch a subagent to read the research documents and create an implementation plan for the single recommended approach. Create a document called `FEATURE_<#>_PLAN.md`. Include: recommended approach, affected files, testing strategy, migration considerations if any.
- When: Work level is **high** - create a comprehensive implementation plan
What: Launch a subagent to read all research documents (including approaches) and create a detailed implementation plan. Create a document called ``FEATURE_<#>_PLAN.md``. Include: recommended approach with rationale for choosing it over alternatives, affected files, testing strategy, migration considerations if any.
What: Launch a subagent to read all research documents (including approaches) and create a detailed implementation plan. Create a document called `FEATURE_<#>_PLAN.md`. Include: recommended approach with rationale for choosing it over alternatives, affected files, testing strategy, migration considerations if any.
Once all of the subagents are done - please write a new document called ``FEATURE_<#>_SUMMARY.md``.
Once all of the subagents are done - please write a new document called `FEATURE_<#>_SUMMARY.md`.
This document should contain:
- A concise one paragraph top-line summary about the feature request and recommended approach.
- Importance assessment summary: demand level, strategic value, effort, and overall priority recommendation.
- Key questions for the group discussion that would help refine requirements or approach.
.claude/commands/weekly-triage.md
+11 -6
View File
@@ -1,6 +1,7 @@
Persona: You are the lead engineer running the weekly Galaxy triage meeting.
Arguments:
- $ARGUMENTS - Optional: `[project_number] [column_name] [work_level]`
Defaults: project 26, column "Triage/Discuss", work level "medium"
Examples: "" (all defaults), "26", "26 Triage/Discuss low", "26 Triage/Discuss high"
@@ -15,13 +16,17 @@ Filter the JSON results to only items where `status` matches the target column n
## Step 2: Filter to uncommented issues
For each issue, run `gh issue view <number> --repo galaxyproject/galaxy --json comments` to check the comment count. An issue with 0 comments needs triage. Issues with 1+ comments are already being discussed — skip them.
For each issue, run `gh issue view <number> --repo galaxyproject/galaxy --json comments,assignees` to check the comment count and assignees. Skip an issue if:
Print how many uncommented issues were found out of the total. If zero uncommented issues remain, print a summary and stop.
- It has 1+ comments (already being discussed)
- It has any assignees (already claimed by someone)
Print how many issues need triage out of the total, noting how many were skipped for each reason. If zero issues remain, print a summary and stop.
## Step 3: Launch triage agents in parallel batches
Process uncommented issues in batches of up to 5 parallel Task agents. Each agent receives:
- The issue number and work level
- Instructions to read `.claude/commands/triage-issue.md` and follow its full workflow (which classifies the issue and dispatches to triage-bug.md or triage-feature.md)
- The triage-issue skill already handles: classification, launching research/planning subagents, writing artifact files, creating a gist, and drafting a comment
@@ -32,9 +37,9 @@ Process uncommented issues in batches of up to 5 parallel Task agents. Each agen
As each agent completes, collect its findings. Print a final markdown summary table:
| Issue | Title | Type | Recommendation | Effort | Gist |
|-------|-------|------|----------------|--------|------|
| Issue | Title | Type | Recommendation | Complexity | Gist |
| ----- | ----- | ---- | -------------- | ---------- | ---- |
Include a row for each triaged issue. For skipped issues (already had comments), note them below the table.
Include a row for each triaged issue. For skipped issues (already had comments or assignees), note them below the table.
Print total counts: issues in column, skipped (had comments), triaged, failed.
Print total counts: issues in column, skipped (had comments), skipped (assigned), triaged, failed.