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 时间较久就自动关闭。

[Astro-Han]

Three updates since my last comment.

#3839 belongs here. I opened it two days before this thread proposing 30 + 7 for PRs; it reached lazy consensus. Landing it separately would decide this thread's PR half early, and only one stale.yml can exist.

ASF practice:

	PR mark + grace	Issue mark + grace
Iceberg	30 + 7	180 + 14
DataFusion	60 + 7	off
Airflow	45 + 5	14 + 7
SeaTunnel	120 + 7	off
Doris	180 + 10	180 + 10
Kafka	90 + 30	—

Long mark, short grace; 7 days is the plurality for PRs. But our queue is three months old — no issue is 60d+ inactive and no PR is 37d+ without a commit, so Iceberg's 180 would never fire here. Proposal: PRs 30 + 7 (matching Iceberg), issues 30 + 30. Grace differs because reopening does: a closed PR keeps its branch and review; a closed issue needs its reporter back.

@YayoiNanoka — I agree 90+30 is too conservative; we differ only on who reviews. Your own staged rollout puts a deterministic workflow under the agent to enforce the wait and perform the action. That layer is what this thread can settle now, and it gives the agent something to be measured against. Sequence rather than choose.

Withdrawing the milestone exemption I proposed — the repo has zero milestones in use, so it exempts nothing. security is unnecessary too (ASF private channel). That leaves stale plus one label, pinned, for long-lived items like #544.

actions/stale cannot express either rule. Its only signal is updated_at:

• All 221 open issues have updated_at within the last day, from the 08-29 bulk issue-type pass. #1685: opened 07-31, zero comments, no engagement, reads as updated 08-29. Configured as written it marks nothing, and every triage pass — including [DISCUSS] Automating issue triage #4177's — resets the whole queue.
• ignore-pr-updates: true is not "only a new commit resets," as I claimed in [DISCUSS] Close pull requests that have had no new commits for 30 days #3839. It switches the comparison to created_at, i.e. pure age. No such option exists.

So staleness must be computed — last human comment for issues, last commit for PRs, one GraphQL query — with actions/stale labelling and closing from an explicit candidate list.

Measured that way: 6 of 221 issues are 30d+ inactive (4 unassigned, oldest 45d); 1 of 146 PRs is 30d+ without a commit. First run marks 5, closes nothing. The real drift is the ≥14d cohort: 32 issues, 16 PRs.

@liugddx — your proposal and survey got this here. Want to take the implementation?

简体中文

我上一条之后有三点更新。

#3839 应并入本帖。 那帖比本帖早两天，提议 PR 30 + 7，已达成 lazy consensus。单独落地会提前定下本帖的 PR 半边，而 stale.yml 只能有一个。

ASF 实际做法：

	PR 标记 + 宽限	Issue 标记 + 宽限
Iceberg	30 + 7	180 + 14
DataFusion	60 + 7	关闭
Airflow	45 + 5	14 + 7
SeaTunnel	120 + 7	关闭
Doris	180 + 10	180 + 10
Kafka	90 + 30	—

普遍是标记期长、宽限期短，PR 的 7 天占多数。但我们的队列只有三个月：没有 issue 沉寂超过 60 天，也没有 PR 超过 37 天无新 commit，Iceberg 的 180 天在这里永远不会触发。建议：PR 30 + 7（对齐 Iceberg），Issue 30 + 30。 宽限期不同是因为重开成本不同——PR 关闭后分支和 review 都在，Issue 关闭后要靠报告者回来。

@YayoiNanoka —— 我同意 90+30 太保守，分歧只在由谁复核。 你的分阶段方案里，Agent 下面仍需一个确定性 workflow 执行等待期和最终动作。那一层正是本帖现在能定的，也给了 Agent 可对照衡量的基准。建议排序，而不是二选一。

撤回我提的 milestone 豁免 —— 仓库 milestone 使用数为 0，豁免不到任何东西。security 同样不需要（走 ASF 私有渠道）。只保留 stale 加一个 pinned，用于 #544 这类长期条目。

actions/stale 无法表达这两条规则。 它唯一的判据是 updated_at：

• 221 个 open issue 的 updated_at 全在最近一天内，来自 08-29 的批量 issue type 处理。#1685：07-31 创建、零评论、无人跟进，却显示 08-29 更新。按提案原样配置，一个都标不上；此后每次 triage（含 [DISCUSS] Automating issue triage #4177）都会清零整个队列。
• ignore-pr-updates: true 不是我在 [DISCUSS] Close pull requests that have had no new commits for 30 days #3839 里说的「只有新 commit 重置」。它是把基准换成 created_at，即纯按年龄。这个选项并不存在。

所以 staleness 必须自己算——Issue 看最后一条人类评论，PR 看最后一次 commit，一次 GraphQL 查询即可——再由 actions/stale 按明确的候选列表打标和关闭。

按此口径： 221 个 issue 中 6 个沉寂 ≥30 天（4 个无人认领，最久 45 天）；146 个 PR 中 1 个 ≥30 天无新 commit。首轮标记 5 项、关闭 0 项。真正在漂移的是 ≥14 天那一档：32 个 issue、16 个 PR。

@liugddx —— 提案和调研是你做的，实现要不要你来接？

(Drafted with AI assistance; I verified the ASF workflow configs, the queue numbers, and the actions/stale behaviour against its documentation myself.)

[liugddx]

Yes, I'll take the implementation.

I'll fold #3839 into this work rather than introduce a competing stale configuration, and implement the agreed deterministic baseline: PRs at 30 + 7, Issues at 30 + 30, activity computed from the last commit / last human comment, and only stale plus the pinned exemption. I'll keep the first-run behavior and comments auditable, add focused tests for the activity calculation and grace-period transitions, and link the PR here once it is ready.

Thanks for checking the live queue and catching the updated_at / ignore-pr-updates limitations.

(Drafted with AI assistance; I reviewed and approved the scope above.)

[liugddx]

Implementation is ready in #4391: #4391

The exact embedded workflow script completed a read-only run against the live tracker with all writes disabled: 373 open items scanned, 5 unassigned Issues and 1 PR selected for warning, and no close actions. I also called out #544 in the rollout note so it can receive pinned before the first mutating scheduled run if maintainers want to preserve it as a long-lived item.

(Drafted with AI assistance; I verified the dry-run result and PR contents.)

[liugddx]

Implementation completed in PR #4391, merged on September 1, 2026. The agreed deterministic baseline is now landed: Issues use 30 days inactive + 30 days grace, PRs use 30 days without a new commit + 7 days grace, with stale/pinned handling and trusted reopen processing. Closing this discussion as the implementation follow-up is complete.