Review Issues Severity

Review Issues by Severity

Parse $ARGUMENTS for optional filters:

• Label filters (e.g., question, bug)
• Focus areas (e.g., "merge disposition", "Arrow", "ClickHouse")
• If absent, perform a broad review across all open issues.

Steps

1. Gather candidate issues

Run the following GitHub API queries in parallel to surface issues matching different severity signals:

a) Long discussions (high comment count)

gh api 'repos/dlt-hub/dlt/issues?state=open&per_page=100&sort=comments&direction=desc&page=1' \
  --jq '.[] | "\(.number)\t\(.comments)\t\(.updated_at | split("T")[0])\t\(.created_at | split("T")[0])\t\([.labels[].name] | join(","))\t\(.title)"'

b) Issues with specific labels (if filters provided)

gh api 'repos/dlt-hub/dlt/issues?state=open&labels=LABEL&per_page=100&sort=comments&direction=desc' \
  --jq '.[] | "\(.number)\t\(.comments)\t\(.updated_at | split("T")[0])\t\(.created_at | split("T")[0])\t\([.labels[].name] | join(","))\t\(.title)"'

c) Recently stale issues (updated 2+ months ago, with maintainer comments)

Look for issues where updated_at is old relative to the current date but had prior maintainer engagement.

2. Deep-dive top candidates

For the top 10-15 most promising candidates, fetch full details using a subagent or parallel gh issue view calls:

gh issue view -R dlt-hub/dlt NUMBER --json title,body,comments,labels,createdAt,updatedAt,author,assignees

For each issue, extract:

• Participants: who commented, their association (MEMBER = maintainer, NONE/CONTRIBUTOR = community)
• Timeline: when maintainers last engaged, how long since last response
• Problem description: what breaks and under what conditions
• Reproduction quality: is there a clean repro script?
• Current status: fixed? workaround? stalled? abandoned?
• Production severity: does this cause data loss, crashes, or silent corruption?

3. Classify each issue

Apply these criteria to each issue:

4. Prioritize

Assign priority tiers:

• P0 — Critical: Silent data corruption, cascading failures, confirmed root cause with no fix. Production systems at risk.
• P1 — High: Hard crashes in common deployment patterns, blocking features for significant user segments, confirmed bugs with stalled fixes.
• P2 — Medium: Broken features in specific environments, intermittent failures, missing warnings that lead users astray.
• P3 — Low: Documentation gaps, environment-specific issues with known workarounds, feature requests with community PRs pending review.

Within each tier, rank by:

1. Seriousness of the problem in production (data loss > crash > degraded performance > inconvenience)
2. Negative community impact if not solved (effort wasted by reporters, users hitting the issue independently)
3. Amount of effort already invested by reporters (repro scripts, root-cause analysis, proposed PRs)

5. Output format

Present results as:

Per-issue analysis (grouped by priority tier)

For each issue:

• Issue link, title, comment count, last activity date
• Problem: 2-3 sentence description of what breaks
• Why this priority: key severity signal
• Abandonment signal: when maintainer last engaged, what was left unresolved
• Community effort: what the reporter invested (repro scripts, analysis, PRs)

Summary matrix

A table with columns: Priority | Issue # | Type | Production Impact | Community Effort | Maintainer Status

Cross-cutting patterns

Note any clusters of related issues (e.g., multiple issues sharing a root cause) or systemic patterns in maintainer response.