The Maintainer's Inbox Problem

If you maintain a popular open source project, you know the feeling. You open GitHub and there are 47 new issues. Some are bugs. Some are feature requests. Some are questions that belong in the docs. A few are duplicates of issues filed last month. And two are from people who didn't read the issue template at all.

Triaging these takes an hour. Every single day. That's an hour you're not writing code, reviewing PRs, or doing the work you actually signed up for.

The good news: you can automate most of this triage for free or near-free. The tooling has gotten surprisingly good.

GitHub Actions: Your Free Starting Point

GitHub Actions is the backbone of open source automation, and you're probably already using it for CI/CD. Issue triage actions are less well-known but equally useful.

Auto-labeling by keywords

The simplest approach. A GitHub Action scans new issue titles and bodies for keywords and applies labels. "crash," "error," "exception" get the "bug" label. "Request," "would be nice," "please add" get "feature-request." "How do I," "documentation," "where is" get "question."

Use the actions/github-script action with a simple keyword map. It takes about 20 minutes to set up and catches 60-70% of issues correctly. Free, runs on GitHub's action minutes.

Stale issue management

The actions/stale action is a classic. Mark issues as stale after N days of inactivity, close them after another N days. Configure different thresholds for different labels: bugs stay open longer than questions, feature requests get a longer grace period.

Be careful with this one. Closing legitimate bugs because the maintainer didn't respond feels hostile to contributors. Set longer thresholds than you think you need (90 days stale, 30 days to close is a reasonable starting point).

Issue template enforcement

GitHub's issue templates are good. But people ignore them. A GitHub Action can check whether required fields in the template are filled out and auto-close issues that skip the template entirely with a polite comment explaining what's needed.

Use stefanbuck/github-issue-parser to extract template fields and validate them. Auto-close with a friendly message that links to the template. This alone reduces low-quality issues by 20-30%.

AI-Powered Triage

Keyword matching works for the obvious cases. AI handles the ambiguous ones.

GitHub Copilot for Issues

GitHub's own offering. It can summarize issues, suggest labels, and identify duplicates. It's built into GitHub and requires a Copilot subscription ($19/month for individuals, free for verified open source maintainers on some projects). The duplicate detection is its strongest feature: it compares new issues against your existing open issues and surfaces potential matches.

Custom classification with webhooks

For projects with high volume or very specific labeling needs, you can set up a webhook that sends new issues to a classification API. When an issue is created, GitHub fires a webhook to your endpoint. Your endpoint classifies the issue (bug, feature request, question, duplicate, needs-more-info) and applies labels via the GitHub API.

Supp's classification API can handle this at $0.20 per classification. For a project that gets 50 new issues per day, that's $10/day or about $300/month. Not free, but for a project at that scale, maintainer time is worth far more.

Self-hosted options

If you want full control and zero cost, several open source tools exist.

issue-label-bot (from Google) uses a pre-trained model to label issues as bugs, feature requests, or questions. It runs as a GitHub App and is free. Accuracy is decent (around 75%) but drops for domain-specific projects.

probot is a framework for building GitHub Apps. You can write custom triage logic in JavaScript. It's more work than a pre-built solution but gives you complete control. Hosting on a free-tier cloud function keeps costs at zero for most projects.

Self-Service Documentation

The best triage is no triage. If someone can find the answer in your docs without filing an issue, everyone wins.

FAQ bots

Set up a GitHub Action that checks if a new issue's text matches common questions and auto-responds with links to the relevant documentation. This doesn't close the issue (that feels dismissive), but it provides an answer immediately while the issue waits for human review.

About 15-20% of issues in most projects are questions that are answered in existing docs. Auto-responding with the right doc link saves the maintainer from copy-pasting the same links repeatedly.

Discussion boards vs. issues

GitHub Discussions is underused. Move questions and general conversations to Discussions and keep Issues for bugs and feature requests. A contributing guide that says "please use Discussions for questions, Issues for bugs" reduces issue volume by 25-35% in most projects.

You can enforce this with a GitHub Action that auto-converts issues labeled "question" to discussions.

A Realistic Automation Stack for Open Source

Here's what I'd set up for a project getting 20+ issues per day.

Issue templates with required fields. A GitHub Action to auto-close issues that skip the template. Keyword-based auto-labeling for obvious categories. A webhook to an AI classification API for ambiguous issues. actions/stale with 90-day stale threshold and 30-day close window. An FAQ bot that auto-responds with doc links for common questions. GitHub Discussions enabled and promoted in the contributing guide.

Total cost: $0 to $300/month depending on whether you use paid classification.

Time savings: 45-60 minutes per day of triage work.

What still needs a human

Triage is one thing. Deciding what to actually fix is another. AI can label an issue as "bug" and even rank it by frequency, but deciding whether to fix it, when to fix it, and whether it conflicts with the project's direction requires human judgment. Don't try to automate that.

Also, community interactions. When a first-time contributor files their first issue, a warm human response matters more than a fast bot response. Consider having bots handle the labeling silently and let humans write the actual replies.

The Burnout Angle

Open source maintainer burnout is a real problem. The issue inbox is one of the biggest contributing factors. Not because the issues are hard, but because the volume is relentless and the triage work feels thankless.

Automating triage isn't about being lazy. It's about protecting the parts of open source that require creativity and care from being crowded out by parts that don't.