“A teammate asked how they managed triage issues efficiently — separate bugs from feature requests from support questions. They started explaining and realized every step ran through github. Specifically, pull request reviews with inline comments had become load-bearing.”
When I'm the maintainer opens github on monday morning, I want to triage issues efficiently — separate bugs from feature requests from support questions, so I can review community PRs without becoming the bottleneck.
A developer who maintains one or more open source projects with 500–50,000 stars. They started the project to solve their own problem and now thousands of people depend on it. They review PRs from strangers, answer issues that are really support questions, and write release notes at midnight. They are simultaneously proud of what they've built and exhausted by the weight of other people's expectations. They do this in their spare time, or they're one of the lucky few who gets paid for it.
To reach the point where triage issues efficiently — separate bugs from feature requests from support questions happens through github as a matter of routine — not heroic effort. Their deeper aim: review community PRs without becoming the bottleneck.
github becomes invisible infrastructure. Triage issues efficiently — separate bugs from feature requests from support questions works without intervention. The old problem — issues that are bug reports with no reproduction steps, filed in a wall of text — is a memory, not a daily fight. AI-powered issue triage that auto-labels, detects duplicates, and requests missing info saves hours weekly.
The maintainer opens GitHub on Monday morning. There are 14 new issues — 3 are duplicates, 4 are feature requests disguised as bugs, 2 are actual bugs with no repro steps, and 5 are genuinely useful reports. There are 6 open PRs — 2 are ready to merge, 1 needs changes they requested two weeks ago with no response, and 3 are from first-time contributors who need guidance. They have 2 hours before their day job starts. They triage 8 issues, merge 1 PR, and close the browser feeling like they didn't do enough.
Maintains 1–5 repositories with 500–50,000 stars. Receives 5–30 issues and 3–15 PRs per week. Uses GitHub Actions for CI/CD. Has 0–5 co-maintainers. Spends 5–15 hours per week on maintenance. Uses labels extensively for triage. Has issue templates and PR templates that contributors sometimes follow. Has considered and possibly set up GitHub Sponsors. Uses GitHub Discussions to separate support from bugs.
The proof is behavioral: triage issues efficiently — separate bugs from feature requests from support questions happens without reminders. They've customized github beyond the defaults — especially GitHub Copilot for AI-assisted coding — and their usage is deepening, not plateauing. Their entire release process is automated through GitHub Actions — no manual deploy steps.
The trigger is specific: drive-by PRs that add features without tests, docs, or context, combined with a high-stakes deadline. github fails them at exactly the wrong moment. Actions pricing became unpredictable as the team scaled — build minutes cost more than their hosting. What makes it irreversible: they fundamentally believe open source is a gift, not a service contract — but users don't always see it that way, and github just proved it doesn't share that belief.
Pairs with github-primary-user (the developer using GitHub daily) for the consumer vs. producer perspective. Use with linear-primary-user for the contrast between OSS issue management and product team issue management. Contrast with gitlab-primary-user for the platform comparison.