The CS Self-Learning Guide licenses its own prose under MIT and points at everything else

The MIT licence stops at the prose, and every linked course keeps its own terms

The licence section has two halves and the second half is the one that matters if you plan to reuse any of this. Parts written by project contributors are under the MIT licence. Everything else is not, and the text says so directly: the remainder, including but not limited to the course resources, open source books and video content mentioned in the book, follows whatever licence the original authors specified. That is the honest and correct arrangement, because those materials belong to other people, but it has a consequence that is easy to miss when the whole thing reads as one artefact. Cloning this repository gets you the writing, the templates and the MkDocs configuration. It does not get you the courses. The genuinely valuable part of a self-study guide is the material it routes you to, and that part is not covered by the licence of the thing pointing at it, so anyone building on this needs to check each destination separately rather than assuming one licence applies end to end.

v1.2.0 is fifteen months older than the last commit, so the tags say nothing

Three release tags exist. v1.0.2 was published on 2023-06-12, v1.1.0 on 2023-12-16 and v1.2.0 on 2025-06-08. The last push to master was on 2026-09-17. Put those dates side by side and the tags stop being a useful signal for this project: the gap between v1.1.0 and v1.2.0 is eighteen months, and the newest tag is about fifteen months older than the most recent commit. Nothing in the tree explains the release cadence, and there is no changelog file in the top-level entries. What actually changes when somebody corrects a course entry is a commit against the `docs/` directory, and a MkDocs build triggered from that. The consequence for a reader is that pinning a tag gives you a guide whose course descriptions may be fifteen months out of date, while following master gives you content that was never labelled or announced. If you cite this guide in a study plan, cite a date rather than a version.

Five plugins are pinned to exact versions and the sixth is not

The site is built with MkDocs, and the entire build dependency list is six lines long:

mkdocs-material==9.5.2
mkdocs-minify-plugin==0.7.1
mkdocs-git-revision-date-plugin
jinja2==3.1.2
mkdocs-static-i18n==1.2.0
mkdocs-open-in-new-tab==1.0.8

Five of those six carry an exact version pin. `mkdocs-git-revision-date-plugin` does not, so it resolves to whatever is current at the moment somebody installs. That matters more than it looks: this plugin is the one that stamps revision dates into the rendered pages, so the unpinned dependency is not a formatting concern, it is the component that decides what date the site claims for its content. The consequence for a rebuild is that a site which rendered correctly when the list was written can render differently, or fail, without any change to this repository. There is also no build instruction in the Chinese README, so a new contributor has to infer that `requirements.txt` is what you install and `mkdocs.yml` is what you run.

A contribution needs two languages, a template and an entry in mkdocs.yml

Contributing a course is described in enough detail to be worth reading twice, because it is three edits rather than one. Use `template.md` as the shape of the new entry, add the course to the navigation in `mkdocs.yml`, and add a short introduction in the matching module of the CS study plan document under `docs/`. Book recommendations go in the recommendations module, following the format given in the comment at the top of that file. On top of those mechanical steps there are two policy requirements. Because the book supports an English edition, every contribution has to come with the corresponding English translation, and the process for that is written up in issue 222. And because the guide mixes Chinese and English typesetting, pull requests are proofread against a separate set of guidelines kept in a third party repository, with the reasoning recorded in issue 114. The consequence is that a Chinese-only pull request is incomplete by the project's own definition, so the real cost of adding one course is two documents plus a review cycle.

mkdocs-static-i18n means a missing translation is a page that exists in one language only

The English edition lives at a separate path on the same site, and the build list includes `mkdocs-static-i18n==1.2.0` for it. The tree carries `template.en.md` next to `template.md`, and an `overrides/` directory for theme overrides. That combination means translation is structural rather than incidental: each page has a counterpart slot, and a page whose counterpart was never written exists in one language and not the other. Nothing in the repository enforces that both are filled, because the plugin has no way to know whether an absent translation is a gap or a deliberate exclusion. The consequence is that the two editions can drift in coverage, and the gap is invisible from the repository alone, since what you see locally is whichever locale you built. Contributors are told to supply the English text, and the review process for that lives in an issue rather than in a check, so the guarantee is social rather than mechanical.

Study groups are announced in issues and run on QQ or WeChat, off the platform

The section on building a community describes a mechanism with no infrastructure behind it. The site supports page comments, so the intended flow is that you start your own group, on QQ or WeChat, and then post a comment under the relevant course page stating what you are trying to learn and how to join. The project adds that a number of readers have already done the same thing in issues, and that you can pick one of those groups instead. So the support layer is a set of chat groups advertised through comments and issue threads, with no server, no moderation process and no account system described anywhere. The consequence is that the accumulated social capital lives in two places nobody controls for longevity: issue threads that can be closed or buried, and third party chat groups whose organisers are individuals. A reader arriving in two years may find the site intact and the community gone, and the repository offers no way to tell the difference in advance.

The two to three year goal is one author's estimate, and nothing here tracks progress

The stated target is specific enough to be worth quoting and loose enough to be worth questioning. It is for a complete beginner to reach a solid mathematical foundation and coding ability within two to three years, after working through dozens of projects measured in thousands of lines, having touched at least C, C++, Java, JavaScript, Python, Go and Rust, and having had some exposure to a long list that runs from algorithms, circuits, architecture, networks, operating systems and compilers through machine learning, computer vision, natural language processing, reinforcement learning, cryptography, information theory, game theory, numerical analysis, statistics, distributed systems, databases, graphics, web development, cloud services and supercomputing. That is a career's worth of subjects, and the repository contains no prerequisite graph, no ordering, no time estimate per course and no way to record what you have finished. The `docs/` tree is a set of written entries following a template. The consequence is that the plan is a reading list with a route sketched through it, and the sequencing, the pacing and the decision to drop something are entirely yours.

The author asks readers to report conceptual errors, which sets the bar for trusting an entry

There is a sentence in the contributor section that tells you how much authority each page carries. It says that because the author's own ability is limited, the book will inevitably contain typos and even conceptual mistakes, and asks readers to raise them in issues rather than be sparing about it. Read as a quality signal it is a warning, not a reassurance, and it is the right thing for a project built out of volunteer-written entries. The consequence for a reader is that an entry is a starting point for your own reading rather than a source to cite. When the guide describes what a course covers, that description was written by somebody summarising a syllabus they did not teach, and the summary is the part most likely to be out of date or slightly wrong. If a course matters to your plan, go to the course's own materials to decide, and use the issue tracker for the guide's accuracy, which is the one thing the project actually asks you to do with it. Around all of this the repository has 75,935 stars and 7,998 forks, and the logo was made by a contributor the README thanks by name.

Editorial conclusion

Use the CS Self-Learning Guide as a map, not as a syllabus. It is a strong answer to the question of which open course to pick for a given subject, it has a Chinese original and an English edition, and the author is explicit that the intended arc runs two to three years. Do not adopt it as a tracked curriculum, because nothing in the repository records which course depends on which, and do not republish it expecting the material to come with it, because the MIT licence stops at the prose and every linked course, book and video keeps its own terms. Before you commit to a plan, read the course entry itself rather than the guide's summary of it, since the author asks readers to report typos and conceptual errors in issues, and check the issue threads for existing study groups instead of expecting support inside the project.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes