Skip to content

Revisit policy of auto-closing issues #6866

Open
@mhucka

Description

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:

Metadata

Assignees

Labels

kind/healthFor CI/testing/release process/refactoring/technical debt items

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions