Add Stale action to TSC project issues and pull requests

[bcantoni]

This project has a very long backlog of old issues, most of which have probably aged out and won't be a priority for solving. Today we have almost 200 issues, the oldest of which is from 2017.

We're better keeping up with PRs: only 17 open, 3 of which are from 2024.

To help manage this better, I propose adding https://github.com/actions/stale which "Warns and then closes issues and PRs that have had no activity for a specified amount of time."

There are a lot of fine-grained controls, but for discussion what if we start with the default configuration behavior:

• Add a label "Stale" on issues and pull requests after 60 days of inactivity and comment on them
• Close the stale issues and pull requests after 7 days of inactivity
• If an update/comment occur on stale issues or pull requests, the stale label will be removed and the timer will restart

We can also define a specific lable like save that would keep that Issue/PR open indefinitely.

@jacalata and @jorwoods what do you think?

[bcantoni]

I dug into (meaning: Claude Code did all this!) the current state of open issues/PRs and the repo's git history to help pick settings rather than just going with the action's defaults. Here's what I found, plus a proposed stale.yml.

What the repo looks like right now

Issues (167 open):

• 61 touched in the last 60 days, but 94 haven't been updated in over a year (54 in the 2–4yr range, 23 over 4 years old). The backlog really is old.
• A big chunk of that "recent activity" is misleading: on 2026-06-18 there was a bulk relabel sweep that touched updated_at on 45 issues with zero actual discussion (checked Auto-Generated Count field unstable during TSC datasource publish #1625's timeline — the only event was a label removal). Since the stale action keys off updated_at, that kind of housekeeping silently resets the staleness clock. Worth knowing going in, since it means a chunk of the "recently active" issues aren't really active.
• A stale label already exists in the repo and has been used manually 4 times (all by @jacalata) to close ancient, unclear issues (Hot to get or Update Datasource information for Teradata and Oracle data sources that use LDAP for authentication. #651, Download data source as .csv directly #318, Request R translation of Tableau Server Client Library #53, Enable setting tags on publish #34). So the concept is already validated here — just not automated yet.
• Labels that signal real "keep this open" intent: good first issue (1 open), Design Proposal (2 open), in-progress (8 open), help wanted (12 open).

PRs (9 open): all from the last 23 days, mostly from maintainers. The "3 from 2024" mentioned above is itself now stale — there's currently no old-PR problem. So the PR side of this config matters much less right now than the issue side.

Recommendations (deltas from the action's defaults)

1. Reuse the existing stale label instead of letting the action create a new one — it already has history/meaning in this repo.
2. Add an exempt-labels list instead of inventing a new save label: exempt good first issue, Design Proposal, and in-progress from ever going stale — these are exactly the cases where "still valid, just not actively worked" is the point. Deliberately not exempting bug/enhancement/help wanted — that's the actual backlog we're trying to clear.
3. Bump days-before-close for issues from 7 → 14 days. This is a one-time flood against an 8-year backlog; maintainers should get a fair shot to rescue anything mid-sweep. (operations-per-run defaults to 30/run, so the initial wave across the 94 old issues will naturally throttle over several days anyway.)
4. Give PRs a longer runway than issues: 90 days before stale, 14 days before close. Community PRs represent real contributor effort; losing one to inactivity is costlier than losing a stale issue.
5. close-issue-reason: not_planned instead of the default "completed" — closing for inactivity isn't the same signal as "fixed," and it keeps closed-reason data meaningful for later triage.

One caveat: the numbers above (167 open issues, 9 open PRs) are current as of today, not the ~200/17 cited when this issue was opened — worth re-checking before merging in case the picture has shifted further.

Proposed .github/workflows/stale.yml

name: Mark stale issues and pull requests

on:
  schedule:
    - cron: '30 1 * * *'
  workflow_dispatch:

permissions:
  issues: write
  pull-requests: write

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9
        with:
          stale-issue-label: 'stale'
          stale-pr-label: 'stale'
          exempt-issue-labels: 'good first issue,Design Proposal,in-progress'
          exempt-pr-labels: 'in-progress'

          days-before-issue-stale: 60
          days-before-issue-close: 14
          days-before-pr-stale: 90
          days-before-pr-close: 14

          close-issue-reason: 'not_planned'

          stale-issue-message: >
            This issue has been automatically marked as stale because it has not had
            recent activity. It will be closed in 14 days if no further activity occurs.
            If this is still relevant, please comment to keep it open.
          stale-pr-message: >
            This pull request has been automatically marked as stale because it has not had
            recent activity. It will be closed in 14 days if no further activity occurs.
            If this is still active work, please comment or push a new commit to keep it open.
          close-issue-message: >
            Closing due to inactivity. If this is still relevant, please reopen or file a new issue.
          close-pr-message: >
            Closing due to inactivity. Feel free to reopen if you'd like to continue this work.

[bcantoni]

@jacalata @jorwoods let me know your thoughts on enabling Stale, and for any feedback on my initial configuration. Let's discuss and agree here, then I can add it in a PR.

[jorwoods]

This approach makes sense to me.

[jacalata]

It seems reasonable. I like the not_planned tag for closing. Go for it.