Uh oh!
There was an error while loading. Please reload this page.
Build the stats page into the site - #259
Conversation
The stats page lived in scverse/stats with its own frontend, so it did not look or navigate like the rest of scverse.org. This renders the same data through the site's own layout, type and tiles, and links it from the About menu. stats.json and contributors.json are still produced by scverse/stats and fetched at build time, the same way the packages page reads the ecosystem registry. The data is a snapshot rather than a time series, so the page is a set of numbers and a contributor list, not the growth charts the issue imagined. Refs #157.
✅ Deploy Preview for jade-cajeta-1bcca0 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
A dark neutral bar disappears under extensions that invert the page, so use the blue from the Join button gradient. It is the only site hue besides the cerise that clears 3:1 against the page, checked rather than eyeballed. "scverse in numbers" stays as the page title, but the menu entry reads Statistics.
Tiles with a destination are anchors and pick up the hover the rest of the site uses — background shift plus a small scale. Only eight of the thirteen link: a tile links out where the destination shows the same number, so Zulip, Bluesky, the org people page, /people, the two packages sections and the org page do, while the pull request and issue counts do not, since a GitHub search covers all 99 org repos and these numbers cover 12. Issues move in with the packages, citations join the community, and the daily download average goes back under the headline figure, which leaves two groups instead of three and nothing stranded.
scverse/stats#9 adds the field. It is scraped from the logged-out company page, so a run that gets blocked will not have it, and the tile is behind a `with` rather than assuming it is there.
Citations sat awkwardly among the community tiles; they belong next to downloads, so the two impact numbers now share the headline row with the citation count set smaller. The remaining contributors go behind a details element rather than a count of people you cannot see. It needs no JavaScript, and the avatars in it are not fetched until it is opened. Drop the sources footnote: the intro already credits scverse/stats, and the contributor paragraph already says the counts are core-only.
Zethson
commented
Aug 14, 2026
@maltekuehl wdyt? To ensure that there's no overlap of URLs, we'd need to switch off the existing https://scverse.org/stats/ . Should we disable the pages build on scverse/stats and make the JSON data easily available? Should we rename the URL here to /statistics or something to not have overlap? |
grst
commented
Aug 14, 2026
Where?
|
Zethson
commented
Aug 14, 2026
What I don't like about renaming is that we still make two frontends for the same content available. I wouldn't be surprised if someone then sent out the wrong URL or takes a screenshot of the wrong thing. |
grst
commented
Aug 14, 2026
ah, I meant using github pages just to serve the latest json. The frontend has to go for sure once it's live on the main website. Using the S3 might require updating some access policies, but probably nbd |
maltekuehl
commented
Aug 14, 2026
There is no reason for the data generation repository to be hosted in any way directly, if we can get S3 upload capabilities there and the website repo can fetch the numbers from there, that would be ideal. |
Renders the stats page with the site's own layout and nav instead of the standalone frontend in scverse/stats, and links it from the About menu.
Data is unchanged:
stats.jsonandcontributors.jsonstill come from scverse/stats, fetched at build time like the packages page reads the ecosystem registry.Blocker: scverse/stats has Pages enabled and owns
scverse.org/stats/, so this page is shadowed in production. It renders on the deploy preview. Freeing that path means renaming the repo or hosting the JSON somewhere else — the JSON isn't committed, it only exists via that Pages deploy.The payload is a snapshot, not a time series, so there are no growth-over-time charts.
Previews may show stale numbers until #254 lands, which stops Hugo caching the remote fetch between builds.
Refs #157.