Currently, the workflow for stale issues (.github/workflows/stale.yml) is set to label something as stale after 30 days of inactivity and auto-close the issue 30 days after that. This is a pretty short duration, so I'd like to propose we review this policy.
Closing inactive issues is a way to reduce the burden on maintainers, of course, but IMHO it's important to balance that against antagonizing contributors. Legit issues don't always see activity within 30 days, and may not be addressable in 60. As it is, we're finding ourselves manually having to reopen some issues, which is actually its own maintenance burden.
Some points to discuss:
- Duration. longer may be better, but infinite duration is also undesirable; we need a happy middle ground.
- Issue types. Maybe some types of issues should have different durations. For example, feature requests could potentially have longer durations.
- Additional procedures. For example, maybe we could add a step of reviewing stale issues & PRs as part of the regular triage process (in biweekly Cirq Cynqs), to decide which ones to deliberately label as
triage/wont-fix or similar.
Additional reading:
Currently, the workflow for stale issues (
.github/workflows/stale.yml) is set to label something as stale after 30 days of inactivity and auto-close the issue 30 days after that. This is a pretty short duration, so I'd like to propose we review this policy.Closing inactive issues is a way to reduce the burden on maintainers, of course, but IMHO it's important to balance that against antagonizing contributors. Legit issues don't always see activity within 30 days, and may not be addressable in 60. As it is, we're finding ourselves manually having to reopen some issues, which is actually its own maintenance burden.
Some points to discuss:
triage/wont-fixor similar.Additional reading: