Skip to content

fix: rank leaderboard header cards by the same averaged data as the charts - #148

Merged
ruyadorno merged 3 commits into
mainfrom
fix/leaderboard-card-ranking
Aug 19, 2026
Merged

fix: rank leaderboard header cards by the same averaged data as the charts#148
ruyadorno merged 3 commits into
mainfrom
fix/leaderboard-card-ranking

Conversation

@ruy-bot

@ruy-bot ruy-bot Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Problem

In the default "average" view, the leaderboard header cards were sorted by wins (counted per raw variation × fixture cell) rather than by the average time printed on the cards — so card #1 could display a slower time than card #2, contradicting the card values and the "Performance Over Time" chart.

Fix

The card values are computed exactly as before: per raw variation × fixture cell, with DNF runs imputed as the slowest successful time for that fixture — the same DNF handling the "Performance Over Time" chart data uses. The only change is the ordering: cards are now ranked by that average time (lower is better) in every view, with wins kept as a tiebreaker only.

Route/data-source selection (usePerPackageData, registry vs task-runner vs package-manager) and the fixture filter behave as before.

Also adds .claude to .gitignore, matching the vlt.io/vltpkg convention of keeping local agent config untracked.

Testing

  • npm run build (tsc + vite) passes
  • npm run lint passes

🤖 Generated with Claude Code

ruy-bot Bot and others added 2 commits August 17, 2026 20:02
The header leaderboard computed its own aggregate — an unweighted mean
over every variation x fixture cell with DNF results silently imputed
as the slowest successful time — and sorted the default (average) view
by wins first. Card order could contradict the times printed on the
cards and the averaged chart data.

Reuse calculateAverageVariationData (the same calculation behind the
charts' average data, which already filters out DNF results) to build
the per-fixture values, and sort by average time in every view so rank
always matches the displayed value.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Matches the vlt.io/vltpkg convention — CLAUDE.md and .claude/ skills
stay local and untracked.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@ruyadorno ruyadorno left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there was a confusion in what "chart data" should have been used as a reference here, the chart that contains the correct calculations is the "Performance Over Time" chart and it does indeed impute the slowest time as the time to be used for a DNF run.

Please change the implementation so that the leaderboard header cards are ordered using that same logic as the "Performance Over Time" chart, the numbers displayed on the leaderboard header cards were correct and the changes to that should be reverted here.

Address review: the leaderboard card numbers were correct (DNF runs
imputed as the slowest successful time, same as the Performance Over
Time chart data) and are reverted to the original calculation. Only
the ordering changes: cards are ranked by that average time in every
view, with wins as a tiebreaker, instead of by wins.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ruy-bot

ruy-bot Bot commented Aug 18, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the catch — you're right, the "Performance Over Time" chart data does impute DNF runs as the slowest time, so the original card values were already consistent with it. I've reverted the value calculation to the original logic (af7a386); the only remaining change is the ordering: cards are now ranked by that same average time in every view, with wins as a tiebreaker. PR description updated to match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants