The GitHub Actions job "prek" on airflow-steward.git/feat-pr-management-stats-trends-codeowners-funnel has failed. Run started by GitHub user potiuk (triggered by potiuk).
Head commit for run: 966533d30689ac3c31e297da7bf3c5b616b5e00a / Jarek Potiuk <[email protected]> feat(pr-management-stats): trends-over-time, CODEOWNERS panel, waiting-bucket split Three related additions to the pr-management-stats spec, all derived from running the skill on apache/airflow (484 open PRs, 6-week cutoff) and finding gaps in what the existing dashboard surfaces. ## 1. Trends over time (panel 3b — 5 sub-panels) Adds a "Trends over time" section between "What needs attention" and "Closure velocity" with 5 inline-SVG line-chart sub-panels: - **Open backlog over time** — end-of-week snapshot of total open count, showing whether the queue is growing/shrinking week-over-week (createdAt ≤ window.end AND (still open OR closedAt > window.end)). - **PRs opened by author class** — per-week `opened` count split by author association (FIRST_TIME / CONTRIBUTOR / MAINTAINER). Surfaces shifts in inflow composition. - **Triage velocity** — count of PRs whose first QC marker comment fell in each week, split by AI-drafted vs manually-typed QC. Surfaces triage throughput. - **Triage coverage rate by week opened** — for PRs opened in each week, % that ever received `is_engaged` maintainer engagement. A declining trend is an early-warning indicator for backlog growth. - **Ready-for-review queue size (cumulative)** — total ready-queue size end-of-week, single line, all areas combined. (Per-area version is the existing panel 6.) Each chart pairs with a per-week table for precise numbers. The classify-and-aggregate path needs no new fetches — all computed from the already-fetched open + closed datasets + the ready-label timeline. Two of the five panels (triage velocity, triage coverage rate) have a documented data caveat: the closed-PR fetch caps `comments(last:25)` per PR, so older outstanding triage markers on chatty PRs are missed. Surface this in the panel. ## 2. CODEOWNERS panel (8b) New panel: "Ready-for-review queue by CODEOWNER". For each entry in the project's `.github/CODEOWNERS`, count how many currently-ready PRs that owner is responsible for (file-pattern match, GitHub's last-match-wins). A PR with multiple owners contributes once per owner. Two extras in the panel: - **Waiting-for-author column** — count of the owner's ready PRs where that owner has personally posted an unresponded comment. Surfaces who the queue is *waiting on the author to respond to* per maintainer. - **"No CODEOWNERS match" row** — currently-ready PRs whose changed files match no rule. Surfaces paths where the CODEOWNERS file could be extended. Needs one new fetch — `pullRequest.files(first:100)` aliased per ready PR — ~8 GraphQL calls for ~150 ready PRs. Cache per `(pr_number, head_sha)`. Skip the panel entirely when `.github/CODEOWNERS` is absent. ## 3. Triage funnel split (panel 9 — 4 → 5 cards) Splits the existing "Waiting for author" hero card into two mutually- exclusive buckets: - **Waiting: AI-triage comment only** — author hasn't responded AND the most recent unresponded maintainer comment is AI-drafted, AND no manual maintainer comment is unresponded. - **Waiting: author response to maintainer** — at least one *manual* (non-AI) maintainer comment is unresponded. Higher priority — this is the real "author owes a maintainer a reply" signal. Implementation uses two new classify-time predicates (`waiting_for_ai_only` / `waiting_for_manual_response`) defined in terms of the most-recent author activity timestamp + the AI-attribution footer substring already used by `is_ai_triaged`. The funnel grid grows 4 → 5 cards; the existing 4 funnel cards (Ready / Responded / Stalest / Velocity) are reorganised in the spec text as well — the new layout has Ready / Responded / AI-only / Manual / Untriaged in precedence order. ## Why upstream now All three improvements proved useful on apache/airflow's queue during maintenance this week. They're project-agnostic (CODEOWNERS is a GitHub feature, AI-attribution footer is the framework's own substring, trends use the same weekly window pattern the existing panels already use), so upstreaming benefits any adopter. The three changes are independent — a reviewer who wants to take only a subset can drop the relevant commit / file edits. They were bundled here because they all touch the same skill and were developed together. Report URL: https://github.com/apache/airflow-steward/actions/runs/26097804086 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
