M2 PR Task Force
A dashboard of pull requests on Macaulay2/M2 — who wrote them, what they're labelled, and
who the task force put on them. Two tabs:
- Open — every open PR that is up for review, plus a reviewer workload table for spreading
review load. That means all non-drafts, and drafts labelled
JSAG — those are opened as drafts
by policy but are still meant to be reviewed. Other drafts are left out.
- Merged — everything merged in the last 3 months, led by how many PRs with a task force
selection merged in the last 30 days and in the full window, plus how many each reviewer approved.
Published daily to GitHub Pages. Run npm start any time to regenerate it locally.
Why the timeline, and not requested_reviewers
GitHub deletes a review request the moment that person submits a review. So "pending
requests" and "has reviewed" are disjoint sets, and neither remembers who did the assigning.
Counting requested_reviewers alone ranks the project's most active reviewer as idle.
This app therefore replays each PR's ReviewRequestedEvent / ReviewRequestRemovedEvent
timeline to recover who assigned whom, and sorts every (PR, reviewer) pair into one of three
origins:
| Origin | Meaning | Can it be pending? |
|---|
| mine | a task force selection: the assigner requested it, on or after the start date | yes |
| other | somebody else requested it — or the assigner did, before the task force began | yes |
| volunteer | nobody ever requested them; they reviewed anyway | no — nothing was ever asked |
Why a start date
The assigner has been requesting reviews as ordinary maintainer work for years, and the API
cannot tell that apart from the task force. Without TASK_FORCE_START the merged view claimed
8 PRs for an effort that had actually produced 2 — the other six were assignments from
April and May, months before the task force existed. Requests made before the cutoff are still
attributed truthfully (the tooltip names the requester and the date); they simply aren't the
task force's own output.
The PR table shows two visual states, because triage only asks one question: bold is a
task force selection, grey is anyone else's (hover any name for who requested it). Bots are
never bold whoever requested them — emphasis is for the humans carrying load.
The page is public, so it names the assigner throughout rather than addressing a "you" that
most readers aren't.
The workload table
The task force's own queue, and only that: one row per reviewer it has put on an open PR —
exactly the pairs the PR table sets in bold. The columns are read off whose turn it
is:
| Column | Meaning |
|---|
| awaiting first review | their move, and they have not reviewed since being picked |
| awaiting follow-up review | their move, and they have reviewed before: the author has answered since, or re-requested them |
| waiting on author | the author owes a reply to a review, so there is nothing to ask this reviewer yet |
Total is all three: a PR waiting on the author is still one the reviewer is assigned. The
split is what matters for "who to ask next" — the last two used to be a single "reviewed, not
approved" column, which ranked a reviewer the author owed three replies alongside one sitting on
three answers.
The bar under Total splits the same way. The reviewer's two stages are one hue at two steps
rather than two different colors: they are stages of one review, so the order should be visible
in the color. The author's move steps out of the hue into a neutral grey, so the blue part of a
bar is always what the reviewer could act on today. The numbers stay in the columns beside it, so
the split never rests on color alone.
Only the first of those exists in GitHub's own view, and counting it alone — as this table used
to — reports the task force's most engaged picks as carrying nothing: the moment they
comment their request is deleted, while the PR still waits on their approval. Total is what
the table sorts on — the load each reviewer carries — and the columns beside it sort too.
Requests the task force did not make are left out, and so are the people who only ever appear
that way. A maintainer who comments on many PRs unasked would otherwise rank near the top of a
table used to decide who to ask, on work nobody asked them for — as one did, at 11. Those
reviews still show on the PR rows, in grey, and the merged tab still credits every approval
whoever requested it. A pick who has answered everything keeps a row at zero: that is what
free capacity looks like, and dropping it would hide the person most available to ask.
TASK_FORCE_START therefore moves rows here, as it does everywhere else.
A PR labelled waiting for another PR counts for nobody: there is nothing to review on it until
the other one lands, and a pick on one is as likely an accident as a plan. It still shows on the
reviewer's page, last, under its own status.
A reviewer's page
Every name on the open tab with a row in the workload table links to that reviewer's page
(#reviewer/<login>): their task force queue, as assigned.sh prints it. It lists the same PRs
as their workload row, in the order to review them. First come the PRs where it is their move,
first reviews and follow-ups together, most pressing first. Then come the PRs waiting on their
authors, and last the ones labelled waiting for another PR, which have nothing to review yet.
Both of those groups put the longest wait first.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
