chore: add stale PR workflow

[DevelopmentCats]

Summary

Adds a stale-PR workflow modeled on coder/coder's .github/workflows/stale.yaml, tuned to the cadence requested for the registry:

• A PR with no activity for 15 days gets the stale label.
• A PR with the stale label is closed 3 days later if it sees no further activity.
• A PR labeled waiting-for-info is exempt from the stale flow.
• Issues are not affected (issue stale flow is disabled).
• Runs daily at 00:00 UTC and via workflow_dispatch.

Also documents the policy in MAINTAINER.md so reviewers know when to apply waiting-for-info.

Why mirror coder/coder's setup

Same action pins (actions/stale@v10.2.0, step-security/harden-runner@v2.17.0), same permissions scoping, same operations-per-run: 60 / ascending: true defaults, and empty stale/close messages to avoid PR-thread noise. This keeps the registry's workflow style aligned with the main product repo and passes zizmor at min-severity: high (which the registry already enforces on every workflow PR).

Action required from a maintainer to finish this PR

The agent that opened this PR runs through a GitHub App that intentionally lacks the workflows: write scope, so it cannot push files under .github/workflows/ directly. Two small steps are needed:

1. Commit .github/workflows/stale.yaml to this branch

Via GitHub UI on this branch: Add file → Create new file, path .github/workflows/stale.yaml, paste the YAML below, commit directly to chore/stale-pr-workflow.

name: Stale PR Cleanup

on:
  schedule:
    # Daily at 00:00 UTC.
    - cron: "0 0 * * *"
  workflow_dispatch:

permissions:
  contents: read

jobs:
  stale:
    runs-on: ubuntu-latest
    permissions:
      # Needed to label and close pull requests.
      pull-requests: write
      # actions/stale walks issues too even when the issue flow is disabled.
      issues: write
    steps:
      - name: Harden Runner
        uses: step-security/harden-runner@f808768d1510423e83855289c910610ca9b43176 # v2.17.0
        with:
          egress-policy: audit

      - name: Mark and close stale PRs
        uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10.2.0
        with:
          # PR stale flow: 15 days idle -> "stale" label -> +3 days -> close.
          days-before-pr-stale: 15
          days-before-pr-close: 3
          stale-pr-label: stale
          # PRs waiting on a contributor reply are exempt; the reviewer
          # has done their part and the ball is in the author's court.
          exempt-pr-labels: waiting-for-info
          # Match coder/coder: no message, just label + close to avoid noise.
          stale-pr-message: ""
          close-pr-message: ""

          # Only manage PRs here; the issue stale flow is intentionally off.
          days-before-issue-stale: -1
          days-before-issue-close: -1

          # Match coder/coder defaults so the runner deterministically
          # works through a large backlog oldest-first.
          operations-per-run: 60
          ascending: true

2. Create the stale label on the repo

actions/stale does not auto-create labels. Before the first scheduled run, create the label on coder/registry:

• Name: stale
• Color: #ededed (or any neutral gray)
• Description: "Marked stale after 15 days of inactivity; closes after 3 more."

The waiting-for-info label already exists and is being used as the exempt label as-is (lowercase, hyphenated).

Verifying after merge

Kick off the workflow with workflow_dispatch from the Actions tab to confirm the action wires up correctly. With no PRs over the 15-day threshold yet, the run will be a no-op and just log how many PRs it scanned.

Design notes / decisions

• 15/3 day cadence (vs coder/coder's 7/3) chosen per the request — the registry has more external community PRs and a longer first-touch window than the product repo.
• exempt-pr-labels: waiting-for-info uses the existing label exactly as it is on the repo (lowercase, hyphenated). No rename.
• stale-pr-message: "" / close-pr-message: "" matches coder/coder — keeps PR threads clean. Easy to add a friendly contributor-facing message later if we decide we want one.
• Issue stale flow disabled via days-before-issue-stale: -1 / days-before-issue-close: -1 so this workflow is scoped strictly to PRs as requested.
• step-security/harden-runner matches the security baseline used across the registry's other workflows (version-bump.yaml, zizmor.yaml, check_registry_site_health.yaml).
• Out of scope (happy to do as follow-ups): the branch cleanup and workflow-run cleanup jobs that coder/coder's stale.yaml also contains; an issue stale flow; a contributor-facing stale message body.

---

🤖 Generated with Coder Agents using Claude (Sonnet 4.5). The MAINTAINER.md change in this PR was committed by the agent; the workflow file in .github/workflows/stale.yaml needs a maintainer commit due to the agent lacking the workflows: write GitHub App scope.

[Copilot]

Pull request overview

Documents a proposed stale pull request policy for coder/registry, intended to align with the actions/stale-based approach used in coder/coder, with a 15-day stale / 3-day close cadence and a waiting-for-info exemption.

Changes:

• Add a “Stale PR Policy” section to MAINTAINER.md describing labeling/closure behavior and exemptions.
• Link the policy to a Stale PR Cleanup workflow file path under .github/workflows/.

[matifali]

Let's do all no exception for waiting-for-info label.

I wanted to only use that on issues. For PRs let's be uniform and use 15 days

[bpmct]

So excited for this!! I think this will improve both the contribution experience (contributors get faster responses) and the maintainer experience (clear queue of issues that are ready for maintainer review)

This PR seems to just add the policy to MAINTAINER.md, but not the policy itself. We should have this as a draft PR until it's ready for review.

[bpmct]

I'm not sure I understand this. Should this be reversed?

If a PR author takes 15+ days to respond, the PR should probably be stalled and closed. However, if the author is waiting on a maintainer (e.g. you, me, Adele) then the author shouldn't be penalized.

Also I think (in this PR) we should set up a bot to automatically apply/un-apply and perhaps change the label to waiting-for-maintainer.