You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Closed as not planned. Superseded by the direct-maintenance rule in #1148 and the closed #1501.
This issue correctly observed that fast-moving code leaves stale issue descriptions, duplicate symptoms, and unclear PR ownership.
Its proposed replacement—typed issue forms, a custom triage state machine, root-cause child tables, ownership checks, linked-PR enforcement, scheduled hygiene reports, project fields, and repository-wide backlog migration—would create another coordination system and source of truth.
Simpler practice
Use normal GitHub behavior:
include an observed revision/reproduction in a defect when it matters;
verify current main before implementing a stale report;
use ordinary closing keywords for fully resolving PRs;
link duplicates/superseding issues directly;
revise or close an architecture issue when the target architecture changes;
preserve unique evidence in a comment/body only when still relevant;
A maintainer may add or improve a small issue template when recurring low-quality reports demonstrate the need. Do not require several issue types, workflow labels, project fields, or a scheduled bot before ordinary work can proceed.
Do not introduce
a custom issue-state machine or required triage label taxonomy;
canonical root-cause owner/child registries;
issue/PR ownership automation;
source-line disappearance/revalidation bots;
scheduled backlog hygiene services/reports as required architecture;
project-management schemas/forms for every issue class;
Disposition
Closed as not planned. Superseded by the direct-maintenance rule in #1148 and the closed #1501.
This issue correctly observed that fast-moving code leaves stale issue descriptions, duplicate symptoms, and unclear PR ownership.
Its proposed replacement—typed issue forms, a custom triage state machine, root-cause child tables, ownership checks, linked-PR enforcement, scheduled hygiene reports, project fields, and repository-wide backlog migration—would create another coordination system and source of truth.
Simpler practice
Use normal GitHub behavior:
mainbefore implementing a stale report;A maintainer may add or improve a small issue template when recurring low-quality reports demonstrate the need. Do not require several issue types, workflow labels, project fields, or a scheduled bot before ordinary work can proceed.
Do not introduce
Canonical reference