Every engineering lead has a story about the day the issue inbox ate their morning. Forty new tickets overnight, half of them duplicates of last week's, a quarter of them in the wrong repo, three of them actually critical. By the time the meeting starts the lead is fifty tickets deep and has not yet read any of them with attention. This post is about a different shape — one where the morning sweep is fifteen minutes because the rule set does most of the work, and the digest tells the lead what the rules did and what still needs eyes.
Why issue triage eats a morning
The first reason is speed: a new issue has to be read before anything else can happen, and reading forty of them takes a real human block of time. The second is judgement: most issues need at least one of what repo is this for, is this a dupe, which label describes it, and who should look at it first — four decisions, made forty times, made badly under pressure. The third reason is implicit: every one of those decisions is a small piece of context the system already has, but the human has to reinvent it every time a new issue lands.
When you name each reason out loud, the fix for each one falls out. Speedis a batch problem — don't do it issue-by-issue, do it once a day across the whole backlog. Judgement is a rule problem — encode the four decisions per repo and let them run on every incoming issue. Implicit context is the digest problem — the system records what it did, and the lead reads the digest, not the issue view.
The four small decisions, automated
For every connected repo, Bowerpost accepts four sets of rules. Auto-label applies a label based on keywords in the title and body — bug, feature, regression, whatever fits your conventions. Dedupe checks incoming issues against open and recently-closed ones by text similarity, and posts a comment on a probable duplicate linking back to the original. Routing assigns the issue to a maintainer or a team based on path patterns in the title or labels that were already applied. Stale marks issues that have been open long enough with no activity to deserve a follow-up ping, so the backlog never grows teeth.
Each rule is opt-in per repo. Most repos turn all four on within the first week. High-traffic repos often add a fifth — a custom acknowledge comment that closes the loop with the reporter — so a forty-ticket morning becomes forty acknowledged tickets plus a single one-line digest summary of what needs eyes.
The fifteen-minute morning
Here's the shape the morning takes once the rule set is in place. The lead opens the digest — twenty lines, one per repo, each line summarising what got labelled, what got deduped, what got routed, and what did not get a rule match. The last bucket is the one that matters: those are the tickets a human needs to look at. On a healthy week, the bucket is three or four per repo. The lead scans them, replies to anything that needs a real answer, and moves on. The rules took care of the other ninety percent; the diary keeps the record of what the rules did, so the lead can audit a rule on any day in two clicks.
What makes this shape durable is that it is the same shape every day. There is no Friday-morning-rush, no Monday-cleanup, no special handling for “this week there were a lot of duplicate bug reports.” The setup was a one-time configuration; the daily cost is bounded and small. The lead's morning is fifteen minutes of actually making decisions, not fifty minutes of clerical work followed by fifteen minutes of decisions.
Rule maintenance, on the digest
Rules are not free. A label rule that matches too broadly will misclassify real bugs; a dedupe threshold set too tight will merge distinct issues; a routing rule keyed on the wrong path will dump issues on the wrong team. The natural temptation is to write increasingly clever rules to forestall every failure mode — and the natural failure of that is that the rule set becomes a parallel codebase nobody wants to maintain.
The digest is what keeps the rule set small. Every morning, the lead can see what the rules did and which decisions required a human override. When an override happens twice in the same week for the same reason, that's a signal the rule needs updating — and the digest line for that repo will show both the override and the underlying trigger. Over months, the rule set tightens, and the override bucket shrinks. The lead is not maintaining a system, the lead is maintaining a habit of reading the digest.
If that sounds like the rest of Bowerpost— a single nightly batched view, a one-line digest per repo, the rule set doing the work the lead used to do — it's because it is. Issue triage is the same shape as drift detection and CI status. The point of any of these is the same: give an engineering lead a system-level view that is small enough to actually read.
Try it on a repo
The issue triage rules live under /dashboard/triage-rules for any connected repo. Auto-label and dedupe are on by default once a repo is connected; routing and stale rules are one toggle each. The morning digest that summarises what the rules did arrives with the same email as the rest of the platform view — CI failures, drift, stale PRs — so the triage sweep and the platform review happen in the same fifteen minutes, not two separate windows.
If you'd like help writing a rule set — or you'd rather talk through the shape before turning any of it on — write to bowerpost-2@polsia.app. We read every message; the welcome thread goes to the same inbox.