BTW. The dashboard (link: https://htmlpreview.github.io/?https://gist.githubusercontent.com/potiuk/ef446baff0fa2972951b5eb5a3826dcf/raw/pr-dashboard-v3.html) is a first draft (even if it is already pretty good, usable and actionable) created literally this morning, from the scratch - through less than hour of agent iteration.
I have submitted PRs to Airflow ( https://github.com/apache/airflow/pull/66464) and airflow-steward ( https://github.com/apache/airflow-steward/pull/68). I am currently syncing these but will soon switch Airflow to use steward skills exclusively. I also built the capacity for projects to keep their local modifications by default, with the option to use a separate agent-driven skill to automatically upstream generalized features back to steward. We are truly living in a new era of software development. Thanks, Jarek Potiuk On Wed, May 6, 2026 at 12:02 PM Jarek Potiuk <[email protected]> wrote: > Hi all, > > Two related things this morning, both as a starting point for discussion: > > > 1. NEXT ROUND OF TRIAGE > ======================= > > I ran another full pass of the auto-triage skill against the open-PR > queue. The skill closed the obvious cases on its own (stale-triaged > drafts past the 7-day no-response window, a few rebase-able PRs whose > "failing CI" was actually stale-main pollution, etc.) and surfaced > contributor PRs into the "ready for maintainer review" label so we > don't have to keep re-discovering them. > > The big picture after this round: > > - 459 open PRs (non-bot), 342 from contributors, 187 currently > labelled "ready for maintainer review" (54% of the contributor > queue). > - The triage funnel is doing its job: only ~98 contributor non-draft > PRs are still untriaged, and only 1 is older than 4 weeks. > - The rest of the open queue is mostly drafts (where the author is > in control) and the growing review backlog. > > What changed since last round: the queue of *bad* PRs (mergeable > conflicts not addressed, abandoned drafts, missing CI signals) is > mostly gone — those are now either auto-drafted, auto-closed via > stale-sweep, or rebased. What is *growing* is the backlog of PRs > that are ready and waiting for a human maintainer to actually > review the code. > > > 2. PROTOTYPE TRIAGE DASHBOARD > ============================= > > To make the above legible at a glance, I asked my agent this morning > to build a maintainer dashboard on top of the same data the triage > skill already fetches. It took about an hour, end to end. This is > explicitly a first attempt — not a finished product. > > Live (snapshot, dated): > > https://htmlpreview.github.io/?https://gist.githubusercontent.com/potiuk/ef446baff0fa2972951b5eb5a3826dcf/raw/pr-dashboard-v3.html > > Source HTML (single self-contained page, no JS): > https://gist.github.com/potiuk/ef446baff0fa2972951b5eb5a3826dcf > > What's currently on it: > > - A health rating + four hero cards (queue size, ready count, > untriaged-non-drafts). > - A "What needs attention" panel — deterministic recommendations > derived from rules in the skill spec, each with the exact > slash-command to run for the action. > - Closure velocity for the last 6 weeks (per-week stacked bars). > - Opened-vs-closed momentum (line chart) — answers "is the backlog > growing or shrinking" (last 6 weeks: -56 PRs, shrinking). > - Ready-for-review trend by top-pressure areas (line chart, one line > per area) — surfaces where the review backlog is climbing fastest. > - Closed-by-triage-reason per week (stacked bars) — green = merged, > amber = author-engaged-then-closed, red = stale-sweep close, > grey = closed without ever being triaged. > - Pressure ranking by area (top 8) so the maintainer can pick a > focused 30-minute session. > - Triage-funnel coverage / response-rate metrics. > - Original per-area tables collapsed into "Detailed tables" at the > bottom for anyone who wants the raw numbers. > > Opening discussion: what *else* should be on this dashboard so we > can use it day to day? What's missing, what's noise, what would you > look at first thing in the morning to know what to do? > > > 3. WHAT MAINTAINERS NEED TO DO NOW > ================================== > > The dashboard already encodes my proposed answer for "what to do", > but in plain text: > > - Look at the "What needs attention" panel. Each card is a concrete > slash-command (or pointer to one) that you can paste. > - For most maintainers right now, that's going to be > "/maintainer-review" filtered by an area:* label you care about > — which is also what the "Pressure by area" panel is sorted to > surface. > - The triage skill has handled the bottom of the queue. The top of > the queue (the 187 ready-for-review PRs) needs us, the humans. > > If each of us picks an area we care about and runs a maintainer-review > session against just that area's "ready for maintainer review" PRs, > we move the queue down measurably and the dashboard reflects it on > the next snapshot. > > > 4. FEEDBACK + PRS WELCOME > ========================= > > The dashboard skill is in the same place as the triage skill — both > are in the apache/airflow repo under .github/skills/, with mirrored > copies in apache/airflow-steward. PRs against either are welcome. > > There's also a Slack channel for auto-triage feedback — the dashboard > recommendations and triage decisions are deterministic rules, so if > something feels wrong, it's a rule worth changing. > > And — riffing on the "Intention is all you need" framing > ( https://potiuk.com/intention-is-all-you-need-1379ec41a19c ) — > nothing about either the dashboard or the triage process is fixed > in stone. Both are agent-readable skills, which means the modification > loop is now: notice what you'd like different → describe the > intention to your agent → it edits the skill → propose the change > back as a PR. You don't need to file a feature request, wait for me > to find time, or write the rendering code yourself. If you'd like > the dashboard to show "PRs that *I* requested review on", or > "per-author response rate", or "Helm-chart age distribution" — tell > your agent and it will do it. > > That applies to the triage process itself too. If a triage rule is > producing comments you don't like, or the wrong PRs are being > auto-drafted, the rules live in > .github/skills/pr-triage/classify-and-act.md and are about as > agent-modifiable as anything in this repo. > > Looking forward to feedback — replies on this thread, Slack, or PR. > > Cheers, > J. >
