Skip to content

v0.8.66: Reactivate stale issue cleanup and consolidate duplicate pre-rename backlog #3089

Description

@Hmbown

Problem

The open issue list has a real backlog-cleanup problem, but a blanket "close anything older than one month" rule would close the wrong things.

A safer policy is needed:

  • close issues that are waiting on reporter info and inactive;
  • consolidate duplicate roadmap/request clusters into active epics;
  • preserve release blockers, current milestone work, security, and intentional v0.9.0 roadmap issues.

Right now the repo appears to have stale automation, but it is effectively not active for current issues because the labels it depends on are not present and bug reports are exempt even when they are explicitly waiting on info.

Evidence

  • .github/workflows/stale.yml exists and uses actions/stale@v9 with:
    • days-before-stale: 14
    • days-before-close: 7
    • only-labels: 'needs-info'
    • stale-issue-label: 'stale'
    • exempt-issue-labels: 'pinned,keep-open,bug,security'
  • Current label inventory includes bug, documentation, duplicate, enhancement, invalid, needs-human, question, security, wontfix, but not needs-info, stale, pinned, or keep-open.
  • Query snapshot on 2026-06-11:
    • first 300 open issues inspected;
    • 40 were created before 2026-05-11;
    • only 19 were also last updated before 2026-05-11;
    • many older roadmap issues were updated on 2026-06-10 or 2026-06-11, so creation date alone is too aggressive.
  • Examples of old untouched issues that look like manual triage candidates, not immediate blind closures:
  • Duplicate/request clusters that should be consolidated rather than left as independent roadmap items:
    • GUI / VS Code / web UI requests: #735, #860, #875, #1132, #1264, #1343 overlap with active epics such as #461, #480, #481, and #2580.
    • Mascot/companion requests: #1063 and #1249 overlap partially but differ between an optional command/pet and startup mascot; maintainer should decide whether to merge, defer, or keep one canonical issue.
    • OPENCODE micro-issues: #411, #412, #413, #414, #424, #425, #426, #427, #431, #452, #457, #458, #459, #470 are old v0.9.0 roadmap shards; either label as intentionally kept or roll into a smaller epic index.

Proposed direction

  1. Create or normalize the stale-policy labels used by automation:
    • needs-info
    • stale
    • keep-open
    • pinned if the repo wants that label name, or update the workflow to use existing labels.
  2. Adjust .github/workflows/stale.yml so needs-info issues can actually close after inactivity:
    • keep only-labels: 'needs-info';
    • do not exempt all bug issues once they are explicitly labeled needs-info;
    • keep exemptions for security, release-blocker, keep-open, and pinned.
  3. Add a first manual triage pass before automation starts closing anything:
    • label unresolved stale bug reports as needs-info with a current-version repro request;
    • close obvious discussion/duplicate issues with links to canonical epics;
    • mark intentional roadmap shards with keep-open or consolidate them into an epic and close the shards.
  4. Use updatedAt and labels as the closure basis, not createdAt alone.

Acceptance criteria

  • The labels referenced by stale automation exist, or .github/workflows/stale.yml is updated to use labels that exist.
  • A bug issue labeled needs-info is eligible for stale close unless it also has release-blocker, security, keep-open, or pinned.
  • The first cleanup pass closes or consolidates obvious duplicate GUI/VS Code/web requests into canonical issue(s).
  • The first cleanup pass handles old brand discussion issue(s) with a maintainer note pointing to the rebrand/README work.
  • Old terminal/Windows bug reports are either closed as unreproducible after a needs-info window or kept with current-version repro evidence.
  • Intentional v0.9.0 roadmap shards are explicitly protected (keep-open/epic-linked) or closed as superseded.
  • A dry-run query is documented so maintainers can see the next batch before automation touches it.

Verification

Suggested dry-run queries:

gh issue list --state open --search 'updated:<2026-05-11' --limit 100 --json number,title,updatedAt,labels,url

gh issue list --state open --search 'label:needs-info updated:<2026-05-28' --limit 100 --json number,title,updatedAt,labels,url

gh issue list --state open --search 'created:<2026-05-11 comments:0 -label:keep-open -label:release-blocker -label:security' --limit 100 --json number,title,createdAt,updatedAt,labels,url

Manual verification after workflow/label changes:

  1. Add needs-info to a test/noncritical issue or run actions/stale in dry-run mode if adopted.
  2. Confirm the issue receives the stale warning after the configured inactivity window.
  3. Confirm protected labels prevent closure.
  4. Confirm PRs are still untouched by stale automation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    cleanupCode cleanup, refactor, or maintenance workenhancementNew feature or requestv0.8.66Targeting v0.8.66

    Projects

    Status
    Backlog

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions