OpenGithubs/github-weekly-rank: a weekly star-growth leaderboard, published as a repository

What the weekly rank actually publishes

The repository is a publication, not a program. Its README carries one week's result at a time: a "best project of the week" callout, a top-20 table with rank, project name, total stars and weekly growth, and then a detail block for each entry. The table columns are fixed, so the ranking is a star-growth ordering rather than a total-star ordering. The 2026.09.22-2026.09.27 table, for example, lists NandhaKishorM/laya first at 25.7k total stars with a weekly gain of 21780, and browser-use/jev-ultrafast second at 20.5k total with 12580. That first row is the point of the format: a project with fewer total stars can outrank a larger one on the week's movement.

The audience is narrow and identifiable. People who want a recurring digest of what is climbing, without opening GitHub Trending every day, and people who want the number attached to a date. The README also lists the distribution channels the maintainer runs: a Discover community at discoverhub.cn, an OpenGithub community at open.itc.cn, a WeChat public account, Toutiao, Zhihu, and companion weekly and monthly repositories under the same account. The ranking is one artefact in a set.

How the ranking is assembled and where the data lives

The mechanism visible in the repository is a scheduled write into a Markdown file. The description states the top 20 is updated every Monday at 08:00. The README shows the output of that write: an HTML-styled heading for the week, a Markdown table, and per-project sections. Each detail block repeats the same fields, total star count, weekly growth, monthly growth, open source date, and a one-line project description copied from the project itself.

The repository layout is the other half of the mechanism. Top-level entries are .github/, .gitignore, 2024/, 2025/, 2026/, and README.md. The year directories are the only archive structure the README shows, which suggests the weekly output is filed by year while the README carries the current week. There is no source file, workflow file or script visible in the top-level listing, and the README does not document how the star numbers are collected. Treat the data as a curated snapshot with a date stamp, not as a reproducible measurement you can audit. The homepage, discoverhub.cn/trend/github/rank?type=4, is the hosted view of the same ranking.

Reading it locally: clone, open, and follow the current week

There is nothing to install. The project is consumed as a repository, so the first real use is cloning it and reading the current table. The README does not document a package, a CLI, or a server, and it gives no setup steps beyond the repository address itself.

The README points readers at the GitHub account that hosts the ranking, at https://github.com/OpenGithubs, and at the repository itself, https://github.com/OpenGithubs/github-weekly-rank. Open the README on the default branch, main. The newest weekly heading sits at the top of the file, followed by the best-project callout and the top-20 table. You should see the week's date range in the heading, for example 2026.09.22-2026.09.27, and twenty rows below it.

To keep a local copy current without re-reading the whole file, you fetch the default branch on a schedule that matches the Monday 08:00 update. If the fetch brings no new commit, the week has not been written yet. The README names no notification mechanism; the subscription paths it does list are the WeChat public account, the Toutiao account, the Zhihu account, and the companion weekly and monthly repositories under the OpenGithubs account.

What the format cannot tell you

Star growth is a popularity signal with a short memory, and this ranking inherits every weakness of that signal. A repository can appear at number one on a single week of attention, as the 2026-09-21 open source date and 21780 weekly gain for the top entry show, without any evidence about whether the code works. The README does not attempt to qualify entries by language, licence, or activity, so a stalled project and a busy one are ranked by the same number.

The harder limitation is resolution. The publication cadence is weekly and the update time is fixed, so a project that spikes on Tuesday and fades by Friday looks identical to one that grew steadily across the week. There is no daily series in the README and no per-day breakdown in the table. If you need to know when within the week the growth happened, or how a project's slope changed over several weeks, this format will not give it to you. The year directories may hold past weeks, but the README does not describe their contents or a way to query them, so any historical comparison is manual reading.

Compared with GitHub Trending and star-history tooling

GitHub Trending is the obvious alternative and the difference is in the unit of measure. Trending surfaces repositories by a GitHub-computed popularity signal over a rolling window, and it changes as you refresh it. This project fixes a window to a calendar week, prints the growth number next to each project, and freezes the result in a commit. You get a date and a delta, which Trending does not show you, and you lose the live, always-current view, which Trending gives you for free.

Star-history style tooling takes the opposite approach again. Those tools plot a repository's star count over time as a chart, so you choose the project and read its curve. Here you choose the week and read a list. Neither is a substitute for the other: the chart answers "how did this project grow", the weekly rank answers "what grew this week". If your question is about one repository, a star-history chart is the better instrument; if it is about the field, the weekly table is.

Maintenance, cadence and the licence gap

The last push to the repository was on 2026-09-28, the same day the newest weekly table is dated, and the repository is not archived. That is consistent with the stated Monday 08:00 cadence, and it is the only maintenance evidence the README provides. No releases are listed, so there is no versioned artefact to pin and no changelog to read. The cost of following the project is therefore the cost of reading a Markdown file each week, plus whatever you spend keeping your copy current.

The licence is not stated in the README. It carries no licence section and no licence file appears in the top-level listing, which shows .github/, .gitignore, the year directories and README.md. If you intend to republish the tables, mirror the ranking on a site, or feed it into a product, that is the first thing to resolve with the maintainer, because the README gives you no terms to rely on. Reading it for yourself raises no such question. Note also that the ranking is a derived work about other projects: the descriptions in each detail block are copied from the projects being ranked, and those projects have their own terms.

Editorial conclusion

Adopt it if you want a dated, week-by-week record of which repositories gained the most stars, in a form you can read or subscribe to without running anything. Do not adopt it if you need per-day granularity, historical series for charting, or a stable data endpoint: the README does not document an API, and the yearly directories are the only historical structure visible in the repository. Before relying on it, open the README and check whether the newest weekly heading matches the Monday you expect, because the update is a manual-looking commit and a missed week leaves the previous table in place.

Frequently asked questions

Official sources

1. Issues
2. OpenGithubs/github-weekly-rank on GitHub
3. Project website
4. README