Skip to content

Docs / Stale issues and PRs

Stale issues and pull requests

How developerz.ai reminds and then closes issues and pull requests that are waiting on the person who opened them, the two keys that switch it on, and the settings we recommend.

A project where nothing sits for months is easier to contribute to and easier to run. developerz.ai can keep it that way: it reminds the person a thread is waiting on, and closes the thread when they do not come back.

Both lanes are off until you switch them on. Closing someone's issue or pull request is your decision, so no repository gets it by default, with or without a policy file. This page is the setup we recommend.

# .dz/maintainer/maintainer.yml
version: 1
triage:
  ask_for_repro: true
  # Close a bug report whose reproduction request the reporter never answered.
  close_unanswered_repro_after_days: 14
pr:
  # Close a contributor's pull request that has waited on its author this long.
  close_awaiting_author_after_days: 21

These are the numbers we run on our own open-source repositories. A larger project with slower contributors can raise them; any whole number of days above zero works.

What is never touched

The lanes only act on work that is waiting on an outside contributor.

  • Anything a bot opened, including developerz.ai's own issues and pull requests, Dependabot's and Renovate's. Dependency pull requests have their own handling: see dependency bots.
  • Issues and pull requests by a project member: anyone with write or admin access to the repository (GitHub reports maintain as write), read from GitHub's collaborator permission, not from how GitHub labels the author. Your own backlog is not a stranger's silence. When that access cannot be read on a given day, the thread is left alone that day too. This holds for both settings above, always. The broader quiet-issue setting below skips a member's issue only when triage.skip_project_members is on.
  • Work you have accepted: an issue or pull request with a milestone, an issue with a ready-for-agent or ready-for-human label or a linked open pull request, a pull request held by pr.human_merge, and anything the platform is working on right now.
  • Locked pull requests.
  • Anything waiting on you. A pull request that is waiting for a review from the project is never on the clock, however old it is.

Issues: an unanswered reproduction request

With triage.ask_for_repro on, a bug report that is missing details gets one comment asking for them and the needs-repro label. close_unanswered_repro_after_days decides what happens when the reporter does not answer:

Day (at 14) What happens
0 The request for details is posted.
7 One reminder, which names the close date.
14 The issue is closed as not planned.

Only the reporter's reply stops the clock. A +1 or a comment from someone else does not. The close comment says the report was not judged, and a reply with the requested details reopens it.

Pull requests: waiting on the author

close_awaiting_author_after_days runs a clock only while the next move is the author's:

  • requested changes, or review threads, that they have not answered,
  • a required check that ran and failed,
  • merge conflicts with the base branch,
  • a pull request still in draft.

A required check that was cancelled, timed out or is waiting for a maintainer to approve the workflow run is the project's move, not the author's, and does not count.

Day (at 21) What happens
7 A comment that names what is waiting.
14 A second comment that names the close date.
21 The pull request is closed. A draft gets 7 more days.

A push, a comment, a review reply or a request for review by the author restarts the clock. A pull request whose only problem is a merge conflict is counted from the first comment about it, so it always gets the whole window after being told. An old backlog is never closed in one pass: every pull request gets both comments first, and the close comes at least 14 days after the first one.

The branch is never deleted, and the close comment tells the author how to continue: open a new pull request from the same branch.

Quiet issues of any kind

A third, broader setting exists: triage.stale_after_days with triage.stale_action comments on, or closes, any issue with no activity for that long, whoever it is waiting on. We do not recommend it as a default, because it also acts on issues that are waiting on you. It acts on project members' issues too, unless triage.skip_project_members is on. Use it when you want a hard cap on issue age. See the policy reference.

Turning it off

Remove the key, or set it to false. Reminders already posted stay on the thread; nothing further is posted and nothing is closed.