Data specification · GitHub Trending
How the signal board is built
Must.Read records a dated attention signal, preserves what the source actually showed, and separates observed facts from editorial explanation. The ranking does not measure software quality.
- WindowSeven inclusive UTC datesMonday through Sunday
- CaptureAfter the window closesOne timestamp for facts and publication
- PublishValidated structured recordOverlapping windows are rejected
Ranking
Weekly issues preserve the captured GitHub Trending source order. No additional score or tie-breaker is applied. Rank, weekly stars, total stars, language, and repository identity come from the captured dataset.
Evidence
Repository license, topics, latest observed push, and eligible releases come from GitHub’s API. Release claims appear only when a non-draft, non-prerelease release was published inside the covered week and links to its exact GitHub tag page.
History
Movement compares only adjacent, non-overlapping snapshots from the same series. A project is “new” when it has not appeared before and “returning” when it reappears after an absence. Streaks require consecutive appearances.
Editorial boundaries
Numbers, dates, ranks, charts, and evidence links are deterministic. Topic-backed fit text and evidence-backed cautions are reconstructed and validated at publication. Unsupported causes, performance claims, and quality conclusions are omitted.
What the data cannot tell you
- GitHub Trending is a platform attention signal, not an independent measure of reliability, security, maintainability, or fitness.
- Stars are cumulative and weekly-star counts are source observations; they are not normalized adoption or usage metrics.
- Missing API metadata is shown as missing. Must.Read does not infer a license, release, or maintenance state.
- Historical comparisons begin only after compatible snapshots exist and never invent missing weeks.