Proposal: Should Maka adopt lifecycle management for long-inactive Issues and PRs?

[liugddx]

Background

I would like to discuss how Maka should manage the lifecycle of Issues and Pull Requests (PRs). Mature open-source projects generally do not close an item solely because it is old. They first label it, explain the inactivity, give the author a recovery window, and close it only when there is still no response.

As of 2026-08-28, apache/maka has 123 open PRs and 200 open Issues. The PR queue is currently active. Among Issues, 32 have had no update for more than 7 days and 1 has had no update for more than 30 days. Maka already has PR effort labels and an Issue take/untake ownership workflow, but I could not find lifecycle labels such as stale, inactive, or stalled, nor a scheduled workflow that warns about or closes inactive items.

Reference practices

• Kubernetes: An Issue with 90 days of inactivity receives lifecycle/stale and a bot comment. lifecycle/frozen can exempt it; continued inactivity eventually closes it.
• Node.js: A PR inactive for more than six months receives stalled. Maintainers are expected to contact the author and discuss continuation or a handoff before closing it.
• Apache DataFusion: A PR receives stale after 60 inactive days and is closed 7 days later; a comment removes the stale state.
• GitHub actions/stale: The official workflow follows the same two-stage pattern: label and comment first, then close after a configurable grace period. Labels and milestones can be excluded.

References:

• Kubernetes: https://www.kubernetes.dev/docs/guide/issue-triage/
• Node.js: https://github.com/nodejs/node/blob/main/doc/contributing/pull-requests.md
• Apache DataFusion: https://github.com/apache/datafusion/blob/main/docs/source/contributor-guide/index.md
• GitHub actions/stale: https://docs.github.com/en/actions/tutorials/manage-your-work/close-inactive-issues

Maka proposal

1. Define lifecycle labels and exemptions, at minimum stale, needs-response, roadmap, security, pinned, and blocked.
2. Start with an Issue-only pilot: after 90 days of inactivity, add stale and explain the deadline; close it after another 30 days without activity. A human reply or reopening removes stale and restarts the clock.
3. Keep PR handling manual at first. If the queue later requires automation, label a non-draft PR after 60 or 90 inactive days, notify the author, wait at least another 30 days, and confirm that no review, release, or external dependency is in progress before closing it.
4. Closure comments should explain the reason and provide a path to reopen, add information, or submit a follow-up PR. If a PR is handed off, preserve the original contributor's credit and reusable work.

Questions for the maintainers and contributors

• Would a 90+30 day Issue policy fit Maka, or should the thresholds be different?
• Which labels must always be exempt? Are roadmap, security, and blocked sufficient?
• Should PRs remain reminder-only, or should they eventually use a longer automatic-close window?
• Who can own a periodic review of candidates and false positives?

This thread is for discussing policy only. It does not change the state of any existing Issue or PR.

中文版本

背景

想和维护者、贡献者讨论一下 Maka 的 Issue / Pull Request 生命周期管理。成熟的开源项目通常不会因为条目“创建时间久”就直接关闭，而是先标记、评论提醒，经过缓冲期仍无响应后再关闭。

截至 2026-08-28，我核对到 apache/maka 有 123 个 open PR、200 个 open Issue。PR 当前整体很活跃；Issue 中有 32 个超过 7 天未更新、1 个超过 30 天未更新。当前仓库已有 PR effort 自动标签和 Issue take/untake 认领流程，但没有发现 stale / inactive / stalled 生命周期标签，也没有定时提醒或自动关单 workflow。

其他项目的参考做法

• Kubernetes：Issue 无活动 90 天后加 lifecycle/stale 并评论，可用 lifecycle/frozen 豁免，继续无响应后自动关闭。
• Node.js：PR 无活动超过 6 个月加 stalled，先通知作者并确认是否继续或允许维护者接手，再考虑关闭。
• Apache DataFusion：PR 60 天无活动加 stale，再过 7 天关闭；评论会移除 stale 状态。
• GitHub 官方 actions/stale 也采用“标记 / 评论 -> 等待 -> 关闭”的两阶段流程，并支持按标签或里程碑排除。

初步建议

1. 先定义 stale、needs-response、roadmap、security、pinned、blocked 等标签和豁免规则。
2. 先只对 Issue 试点：连续 90 天无活动时加 stale 并评论，再过 30 天仍无活动才自动关闭；有人回复或重新打开时移除 stale 并重新计时。
3. PR 暂时只做提醒和人工确认。未来如有需要，可在 60/90 天无活动后标记，至少再等待 30 天，确认没有 review、release 或外部依赖后再关闭。
4. 关闭评论应说明原因，并给出重新打开、补充信息或提交新 PR 的路径；PR 如被接手，应保留原贡献者署名和可复用成果。

欢迎维护者和贡献者讨论阈值、豁免标签、PR 是否自动关单，以及后续的维护责任人。