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 是否自动关单，以及后续的维护责任人。

[Astro-Han]

Thanks for writing this up — the reference survey across Kubernetes, Node.js, and DataFusion is really helpful, and starting with an Issue-only pilot plus keeping PR handling manual sounds like the right scope to me.

Two thoughts from looking at the live tracker, offered as suggestions rather than objections:

1. Maybe mark earlier, while still closing conservatively? Maka moves unusually fast — the codebase is only about three months old, and entire subsystems have been deleted within a single month. A 90-day-old bug report here often points at code that no longer exists, so by the time the current threshold fires, the report may no longer be reproducible at all. Marking at something like 30 days of inactivity would catch this earlier, especially if the stale comment asks the reporter to reconfirm against current main — that feels like the question that actually matters in a fast-moving repo. Closing could stay conservative as you proposed: a further 30-day grace period, and only for issues that are waiting on the reporter rather than on a maintainer.

2. Could the label taxonomy start smaller? I suspect the pilot only needs one new label: stale. needs-response might be redundant — the stale comment itself is what asks for reconfirmation, so being stale already means "waiting on the reporter," and any human reply removes it. The exemptions could also come from facts the tracker already has rather than new labels: issues claimed via take have an assignee, roadmap items have a milestone, and actions/stale exempts both natively (exempt-all-assignees, exempt-all-milestones). Security reports go through the ASF private channel rather than public issues anyway, and since any human comment resets the clock, blocked/pinned items that people still care about would survive naturally. For the occasional exception, a maintainer removing stale once seems cheaper than maintaining a permanent label set — and if the pilot shows real demand for any of these labels, adding one later is much easier than retiring one.

For what it's worth, only 1 open issue is currently more than 30 days inactive, so this policy would start out costing nothing and already be in place before the queue ages — which seems like a nice property of adopting it now.

(Drafted with AI assistance; I verified the tracker numbers and workflow details myself.)

中文版本

感谢整理这份提案——Kubernetes、Node.js、DataFusion 的横向对比很有参考价值，先做 Issue-only 试点、PR 保持人工处理，这个范围我觉得是合适的。

对照实时队列数据后有两个想法，作为建议提出，供参考：

1. 标记也许可以更早，关闭仍然保持保守？ Maka 的迭代速度非常快——仓库只有三个月左右的历史，整个子系统一个月内就可能被删掉。90 天前的 bug report 在这里往往指向已经不复存在的代码，等到现有阈值触发时，报告可能早已无法复现。把标记阈值改为 30 天无活动 能更早发现这种情况，特别是如果 stale 评论能要求报告者对照当前 main 重新确认——在快速演进的仓库里，这可能是真正重要的问题。关闭则可以沿用你的保守设计：再留 30 天宽限期，且只适用于等待报告者（而非维护者）响应的条目。

2. 标签体系能不能从更小开始？ 我感觉试点阶段可能只需要一个新标签：stale。needs-response 也许是冗余的——stale 评论本身就是在要求重新确认，被标记即意味着"等待报告者"，任何人回复就会解除。豁免也可以从现有事实派生，而不必新增标签：take 认领的 Issue 有 assignee，roadmap 条目有 milestone，actions/stale 原生就支持这两类豁免（exempt-all-assignees、exempt-all-milestones）。安全问题按 ASF 流程走私有渠道，本不在公开 Issue 里；而任何人工评论都会重置计时，所以仍有人关注的 blocked/pinned 条目自然会存活。个别例外由维护者手动摘一次 stale 即可——如果试点之后发现确实需要某个标签，届时再加也比退役一个标签容易得多。

另外供参考：当前只有 1 个 open Issue 超过 30 天未更新，所以现在建立这个政策几乎零成本，还能赶在队列老化之前就位——这似乎是现在讨论它的一个额外好处。

（本评论由 AI 辅助起草；队列数据和 workflow 细节我已逐一核实。）

[YayoiNanoka]

I agree with introducing lifecycle management, but I think the proposed 90 days inactive + 30 days grace period is too conservative for Maka. The project has only been under active multi-contributor development for a few months and is still evolving quickly, so waiting up to 120 days may provide limited value.

I suggest treating inactivity as a trigger for review rather than a reason for closure:

1. After 30 days without meaningful activity, send the Issue to an automated review workflow.
2. Use an LLM-powered agent, potentially hosted through GitHub Agentic Workflows, to inspect:
   • the Issue and its comments;
   • related Issues, PRs, commits, releases, and current code;
   • whether the reported problem still exists;
   • whether it is a duplicate, already fixed, obsolete, or missing information;
   • whether an assigned contributor is still actively working on it.
3. Apply different actions based on the result:
   • A valid Issue with an inactive assignee should be unassigned and made available for someone else, not closed.
   • An Issue missing essential information can receive a focused request and be closed after another 14 days without a response.
   • A high-confidence duplicate, fixed, or obsolete Issue can enter a short close-candidate period, with concrete evidence included in the comment.
   • Roadmap, security, blocked, valuable, or uncertain Issues should remain open for maintainer review.
4. Any meaningful response should cancel the pending closure.

Technically, GitHub Agentic Workflows should be able to support this. The agent can perform the contextual analysis and produce labels, comments, evidence, and a recommended action. A deterministic GitHub Actions workflow can then enforce the waiting period and perform the final close or reassignment. This keeps the subjective analysis with the LLM while keeping the actual lifecycle rules predictable and auditable.

I would suggest starting with an Issue-only pilot in staged mode, where the agent only reports what it would do. After evaluating its accuracy, we could gradually enable labels and comments, then reassignment, and finally narrowly scoped automatic closure.

In short:

30 days inactive → agent review → evidence-based classification → keep open, request information, reassign, or enter a short close-candidate period.

This would be more responsive than a uniform 90+30 policy while still avoiding automatic closure based solely on age.

中文版本

我赞成引入生命周期管理，但我认为目前建议的“90 天无活动，再等待 30 天关闭”对 Maka 来说有些保守。Maka 正式多人协作开发至今时间并不长，而且仍在快速迭代，最长 120 天的处理周期可能无法及时反映 Issue 的真实状态。

我更建议把“无活动”作为触发复核的条件，而不是关闭理由：

1. Issue 连续 30 天没有有效活动后，进入自动复核流程。
2. 通过 GitHub Agentic Workflows 承载 LLM Agent，检查：
   • Issue 正文和评论；
   • 关联的 Issue、PR、commit、release 和当前代码；
   • 问题目前是否仍然存在；
   • 是否重复、已经修复、已经过时或缺少必要信息；
   • 当前负责人是否仍在推进。
3. 根据结果采取不同操作：
   • 问题有效但负责人长期没有进展：取消分配并重新开放认领，而不是关闭。
   • 缺少必要信息：提出明确问题，再等待 14 天，无回应后关闭。
   • 高置信度的重复、已修复或过时问题：提供具体证据，进入一个较短的待关闭期。
   • Roadmap、安全、阻塞、有价值或无法确定的 Issue：保持打开并交由维护者复核。
4. 等待期内出现有效回应时，立即取消关闭流程。

技术上，GitHub Agentic Workflows 基本可以满足这一需求。LLM Agent 负责结合上下文分析并输出标签、评论、证据和建议操作；普通的确定性 GitHub Actions workflow 负责等待时间、最终关闭和负责人交接。这样既能利用 LLM 的判断能力，也能让真正的状态变更保持可预测和可审计。

建议先只对 Issue 进行 staged-mode 试点，让 Agent 仅展示它准备执行的操作。验证准确率后，再逐步开放标签和评论、负责人交接，最后才启用范围严格受限的自动关闭。

简化后的流程是：

30 天无活动 → Agent 复核 → 基于证据分类 → 保留、补充信息、重新分配或进入短期待关闭期。

这种方式会比统一的 90+30 规则更及时，同时也不会仅仅因为 Issue 时间较久就自动关闭。