Policy Written in Python: When Your Stale Bot Becomes Your Least Accountable Maintainer

Somewhere in your repository right now, a script is making decisions on your behalf. It is closing a bug report filed by a user who took forty minutes to write a detailed reproduction. It is applying a label that will follow that issue for the rest of its life. It is posting a comment in a tone nobody approved. It did this yesterday, and the day before, and it will do it again tomorrow — and if you are like most maintainers, you have never once read the policy it enforces.

Automation in open-source repositories has quietly crossed a line. What started as housekeeping — closing issues abandoned for thirty days, marking stale pull requests — has become a parallel governance structure. And unlike human maintainers, bots face no review, no recall, and no awkward conversations when they get it wrong.

The Quarter You Didn't Supervise

Pull the logs from any mid-sized repository running a stale bot and the numbers are sobering. In a recent audit of a popular US-based data tooling project, the automation closed 214 issues over one quarter. A human maintainer substantively reviewed fewer than a dozen of them. Fourteen of the closed issues described bugs that were still live in the current release.

The pattern repeats across ecosystems. Auto-labelers tag first-time reporters with labels like "needs-repro" or "low-priority" based on nothing more than title keywords. Triage scripts route issues by regex, and a user who writes "crash on startup when using the new API" gets filed under documentation because the word "using" matched a rule. Newcomers — the people every project claims to want — are disproportionately affected, because they are the least likely to know how to reopen a closed issue or appeal a label.

Every one of these actions is a policy decision. Closing an issue after fourteen days of inactivity says: fourteen days is how long this project owes you a response. Auto-labeling says: a machine's keyword match is sufficient evidence to categorize your bug. Most maintainers inherited these scripts from a template, a scaffold, or a copy-paste from another repo, and never consciously ratified any of it.

Three Ways Automation Oversteps

The failure modes cluster into three recognizable categories.

The silent closure. The bot closes an issue for inactivity, but the inactivity was the project's fault — nobody responded. The reporter, having done everything right, receives an automated message that reads, to them, like a door slamming. Many never file another issue. The project's issue tracker looks tidy; the project's reputation quietly bleeds.

The permanent label. Labels are cheap to apply and expensive to remove. An auto-labeler that tags a valid bug report as "question" or "wontfix-adjacent" has effectively buried it. Human triagers scan by label; a mislabeled issue may never surface again. Unlike a human triager's mistake, though, the bot's mistake repeats identically every day until someone notices.

The tone problem. Automated comments are written once, by a developer who was probably having a fine day, and then deployed to thousands of interactions. Messages like "This issue has been automatically closed because it has been open 30 days with no activity" are factually accurate and relationally terrible. There is no apology, no invitation to return, no acknowledgment that the silence may have been the project's.

The Quarterly Automation Audit

The fix is not to eliminate automation — well-run bots genuinely help overwhelmed maintainers. The fix is to treat your automation the way you would treat a volunteer maintainer: with onboarding, oversight, and periodic review. Here is the checklist we recommend running every quarter.

1. Enumerate every actor. List every bot, GitHub App, and CI script that can close, label, lock, or comment. You cannot audit what you have not inventoried. Check repository settings, workflow files, and third-party integrations — half the automation on most repos was installed by someone who has since left.

2. Sample the closures. Pull every issue the automation closed last quarter. Read twenty at random. For each, ask: did a human ever substantively engage? Would a reasonable contributor consider this closure fair? Anything below a ninety percent yes-rate indicates a policy problem, not an edge case.

3. Review the label taxonomy. Dump every machine-applied label and trace the rule that produced it. Delete labels that no human has ever acted on. A label that exists only to be applied and ignored is noise with a name.

4. Rewrite the copy. Read every automated message aloud. If it sounds like a parking ticket, rewrite it. Good automation messages acknowledge uncertainty ("we might have closed this by mistake — please reopen"), name a human path forward, and never pretend the silence was the reporter's fault.

5. Add an appeal path. Every automated action should be trivially reversible by a non-expert. If reopening a bot-closed issue requires knowing a magic command or pinging a specific maintainer, your appeal process is broken.

6. Ratify the policy in public. Write down, in a visible document, what your automation does and why. "We close issues after 30 days of project inactivity, not reporter inactivity" is a policy. "The bot does what the bot does" is an abdication.

Automation Is a Governance Question

Open-source projects have learned, painfully, to make governance explicit — decision records, maintainer guidelines, codes of conduct. Automation deserves the same treatment precisely because it is governance: it allocates attention, signals priority, and decides whose contributions get seen.

The bots are not going away, and they should not. But a script that closes two hundred issues a quarter is a maintainer with perfect attendance and zero accountability. Audit it like one.