[DISCUSS] Close pull requests that have had no new commits for 30 days

[Astro-Han]

I propose we automatically close a pull request whose author has not pushed a new commit for 30 days, after a 7-day warning. Comments would not reset the timer — only a new commit does. A closed PR can be reopened at any time.

I intend to proceed by lazy consensus: I will wait at least 72 hours, longer if discussion is still active, and summarize the outcome here before opening a PR.

Where to object: this Discussion is relayed to dev@maka.apache.org, but the bridge is one-way — a reply sent to the list will not appear here. I will watch both and fold anything raised on the list back into this thread.

Proposed workflow

name: Close stale pull requests

on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

permissions:
  pull-requests: write

jobs:
  stale:
    if: github.repository == 'apache/maka'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
        with:
          days-before-pr-stale: 30
          days-before-pr-close: 7
          ignore-pr-updates: true
          exempt-draft-pr: false
          exempt-pr-labels: 'pinned,security'
          days-before-issue-stale: -1
          days-before-issue-close: -1
          operations-per-run: 200
          stale-pr-message: >
            This pull request has had no new commits for 30 days and has been
            marked stale. It will be closed in 7 days unless a new commit is
            pushed. Comments do not reset this timer — only a new commit does,
            so that a maintainer following up cannot keep a PR open on the
            author's behalf. If this PR is blocked on a decision rather than on
            you, say so and we will apply an exempt label.
          close-pr-message: >
            This pull request has been closed because it had no new commits for
            37 days. This is not a judgement on the merit of the change in any
            way — it is only a way of keeping the review queue honest about what
            is actually in flight. You can reopen it at any time and we will
            pick the review back up.

Why, from our own data

I read all 127 open PRs before writing this rather than copying another project's settings.

Thirteen PRs have had no new commit for 14 days or more, and in twelve of them the ball is with the author — the last event is a maintainer comment or a review-bot comment, and the author has not pushed since. The one exception is my own draft, #1916. Four of the twelve are already approved; the rest are split between CHANGES_REQUESTED and REVIEW_REQUIRED.

This matters because the strongest ASF argument against auto-closing is that it punishes contributors for our review latency. That argument is sound in general and does not describe this repository right now.

Why the timer counts commits, not activity

actions/stale measures updatedAt by default, which any comment resets. Every Apache project I checked uses that default — Iceberg, Airflow, Spark, Beam, Arrow, Doris, Flink.

Here it would measure the wrong thing. Under the activity clock, zero of our 127 open PRs are stale at 30 days. Not because nothing is abandoned, but because maintainers sweep the queue and a review bot comments; almost every updatedAt currently traces to one batch of follow-up comments I posted on 2026-08-23. An activity clock would measure how often we nag. ignore-pr-updates: true decouples the two, so we can keep following up without silently keeping dead PRs alive.

Why drafts are included

AGENTS.md asks contributors to open published PRs as drafts, so draft is our normal starting state, not a signal of abandonment. Exempting them would exempt much of the queue for no reason related to what we are measuring — and it would change little either way: of 17 open drafts, one has gone 14 days without a commit and none has gone 30.

Why 30 days

Other projects' numbers are calibrated to their own tempo (Iceberg 30/7, Airflow 45/5, Spark 100/0), and Maka is about three months old. PRs with no new commit for at least N days:

N	7	14	21	30	45
PRs	28	13	8	1	0

45 days would be inert at our tempo. 14 is too aggressive — two weeks away should not cost you a PR. 30 is where the distribution thins out, and today it would mark exactly one PR, #1253. I would rather start with something close to a no-op that ages well than clear a backlog we do not have. Worth revisiting after a quarter with fresh data.

The objection I expect

Closing an approved PR feels wrong, and four of the twelve are approved. I think it is still right: branch protection dismisses approvals on any new commit, and at our merge rate a branch untouched for 30 days is almost certainly conflicting already — #3299 and #3723 both went DIRTY within a day or two of main moving. The approval has not survived; closing only makes that visible, and reopening is one click.

If the community disagrees, an easy amendment is to exempt approved PRs and close them by hand.

ASF notes

• I found no foundation-wide rule requiring or forbidding this; it is a per-project convention, and a common one — seven of the eight Apache projects I checked run a stale workflow.
• No INFRA allowlist request is needed: the GitHub Actions Policy allows actions/* without restriction. I pinned the SHA anyway, as Airflow and Iceberg do.
• Permissions are minimal and the trigger is schedule only, never pull_request_target. If the first run shows issues: write is also needed to label PRs, I will say so rather than widening it quietly.
• The 30-day window, the commit-based timer, and the wording of both bot messages all follow from community over code: a distributed community participates asynchronously, a maintainer's nudge should not start anyone's clock, and closing must state plainly that it is not a judgement. The wording is adapted from Apache Iceberg's.
• Reversible: if it turns out wrong we delete one file, and nothing closed is lost.

Objections, different numbers, or a different measure entirely are all welcome.

---

Disclosure per AGENTS.md: I used Claude Code (Opus 5) for the data in this proposal — the 127-PR survey, the commit-age distribution, the waiting-on-author classification, and the comparison against other Apache projects' stale.yml. I checked its output against the repository and the linked ASF pages. The position argued here is mine.

[M4n5ter]

+1
I approve of this