Hi Jarek, Awesome dashboard, I love it! Here is my feedback. I hope it is helpful, though I'm not sure how difficult it would be to implement 😅
1. List PRs that do not have any requested reviewer or requested team yet. I noticed that not every part of Airflow has CODEOWNERS, so I think it would be helpful if we had this list or table. 2. It might also be useful to split ready-for-review PRs by review size, for example small / medium / large, based on files changed or lines changed. Maybe we could reuse the same logic as CI or selective checks. 3. Add an entry link where maintainers can check all PRs that need their review, for example https://github.com/pulls. Thanks, Aaron On Wed, May 6, 2026 at 3:45 AM Jarek Potiuk <[email protected]> wrote: > 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. > > >
