Heuristic:Kubeflow Kubeflow Stale Issue Lifecycle Management
| Knowledge Sources | |
|---|---|
| Domains | Issue_Management, Contributing, Automation |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Issue lifecycle management pattern using 90-day stale marking and 7-day auto-close with priority and project exemptions.
Description
The Kubeflow project uses the Probot Stale GitHub App to automatically manage inactive issues. Issues that have not had any activity for 90 days are marked as stale with the lifecycle/stale label and a notification comment. If no further activity occurs within 7 days of the stale marking, the issue is automatically closed. This prevents the issue backlog from growing unboundedly with abandoned or obsolete issues while preserving important tracked work.
Usage
Use this heuristic when configuring issue lifecycle automation for Kubeflow repositories or when understanding why an issue was automatically closed. It applies to all issues in the kubeflow/kubeflow repository. Issues that are actively planned work (in projects, milestones, or with priority labels) are automatically exempted.
The Insight (Rule of Thumb)
- Action: Configure Probot Stale with
daysUntilStale: 90anddaysUntilClose: 7. - Value: 90-day inactivity window before stale marking; 7-day grace period before closure.
- Trade-off: Some valid but slow-moving issues may be auto-closed. Mitigation: use exemption labels.
- Exemption strategy: Issues with any of the following labels are never marked stale:
lifecycle/frozenpriority/p0,priority/p1,priority/p2,priority/p3
- Additional exemptions: Issues added to a GitHub Project or Milestone are also exempt.
Reasoning
Open source projects with many contributors accumulate issues that are no longer relevant due to version changes, duplicate reports, or issues that were fixed without being explicitly closed. The 90-day window is generous enough to avoid closing issues that are actively being discussed but slow to resolve, while the 7-day grace period gives the original reporter and maintainers time to respond if the issue is still relevant.
The exemption strategy is the key design decision: by exempting issues with priority labels, project board membership, or milestone assignment, the stale bot only targets truly abandoned issues. Issues that maintainers have explicitly triaged and prioritized are never affected.
From .github/stale.yml:L28-41, the stale notification message explicitly explains the exemption criteria to affected users:
Issues never become stale if any of the following is true:
1. they are added to a GitHub Project
2. they are added to a GitHub Milestone
3. they have a priority label: priority/p0, priority/p1, priority/p2, priority/p3
4. they have the frozen label: lifecycle/frozen