Publish a daily cross-repository Babel milestones page to GitHub Pages

[gaurav]

Milestones are the commitment mechanism across the Babel repositories, but they cannot span
repositories — so "what have I actually committed to?" currently means visiting five separate
milestone pages across two organizations. This adds a tool and a daily workflow that merge them
into one chronological page.

A first pass, meant to be iterated on. It is already useful for the milestone cleanup it makes
visible: 18 open milestones, 7 of them past due, and two empty Translator June Hackathon 2026
milestones that can just be closed.

What's here

• src/babel_validation/tools/milestones_page.py — reads open milestones and their open issues
  from the five repos, sorts by due date (undated last), writes a self-contained HTML file.
  Legacy priority-bucket milestones (Immediate, Needed soon, …) are undated and never close,
  so they get their own section instead of sorting among real deadlines.
• .github/workflows/milestones-page.yaml — runs it daily and on demand, deploying to
  gh-pages:milestones/. It publishes to a subfolder so it does not clobber the Astro site that
  deploy-website-to-gh-pages.yaml puts at the root on release.
• docs/milestones-page.md — the design rationale and the list of known gaps.
• tests/tools/test_milestones_page.py — covers the undated-sorts-last ordering and bucket detection.
• deploy-website-to-gh-pages.yaml — gains clean-exclude: milestones/. It deploys to the root of
  gh-pages and cleans by default, so without this every release would delete the milestones page,
  leaving it missing until the next daily run.

Why generated rather than a GitHub Project

A cross-repo project board was the obvious alternative. A board is a second record of commitment
that has to be kept in step with the milestones by hand, and drifts as soon as that stops
happening; this page is derived, so the milestone is the only input and there is nothing to sync.
A board also can't answer the question that matters most from outside — roughly when someone's
issue will be looked at — whereas a public URL can.

Automating a board is also expensive: the built-in auto-add filter supports only
is/label/reason/assignee/no (not milestone:) and never removes items, so keeping one in
step would need an Action in all five repos listening for milestoned/demilestoned, plus a PAT
with project scope as an org secret in both organizations.

The constraint worth preserving: all five repositories are public, so the built-in
GITHUB_TOKEN reads them across both orgs with no secrets to configure or rotate. Reading fields
off a GitHub Project would break that. Priority and component should therefore live in labels.

What's given up is drag-to-rank ordering within a milestone; a priority: label is the intended
substitute.

TODO — decide whether to fix here or file

• Render priority:/component labels distinctly and sort on them. Labels are the agreed
  substitute for drag-to-rank ordering on a board, but no label scheme exists yet, so this
  needs that decision first.
• Drop BUCKET_TITLES once the legacy priority-bucket milestones (Immediate, Needed soon,
  Needed later, Not urgent) are cleaned up — it only exists to recognise them.
• Reconcile the two workflows both named Tests: test.yml on split/2-top-level-package
  and tests.yaml on six branches including split/3-github-issues. Neither is on main
  yet, so they will collide when those branches merge.

Deliberately not done

• Labels render undifferentiated — no priority/component sorting yet.
• Closed milestones are ignored, which hides ~253 open Babel issues parked in closed milestones
  (Needed soon 87, Needs tests 54, Needs investigation 46, …). Filed as
  Open issues parked in closed milestones are invisible to every milestone view NCATSTranslator/Babel#1048.
• No grouping by repository or component; one flat list.
• Styling is minimal on purpose.

Verified by running against the live API: 18 milestones, 180 open issues.

🤖 Generated with Claude Code