# The Turing Way: a reproducible research handbook built as a public repository > Eighteen hundred contributors' worth of institutional memory, published with Netlify, checked for placeholder text by CI, and translated by hand into nine languages. **the-turing-way/the-turing-way** — Book repository for The Turing Way: a how to guide for reproducible, ethical and collaborative data science - Repository: https://github.com/the-turing-way/the-turing-way - Website: https://book.the-turing-way.org/ - Stars: 2,194 · Forks: 783 - Language: TeX - License: NOASSERTION - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/the-turing-way-the-turing-way ## A book repository where the contributors are the point The README opens with an all-contributors badge reading 576, which for a handbook is the headline metric rather than a footnote. The project describes itself as four things at once, illustrated in a single image: a book, a community, an open source project and a culture of collaboration. Fork count tells part of the story, at 775 against 2180 stars, which is a fork ratio far above a typical codebase and consistent with a document that people want to translate, adapt for their own institution, or teach from. The GitHub description calls the repository a book repository for a how to guide for reproducible, ethical and collaborative data science, and the topics are only `community`, `data-science` and `education`. There is no software topic, no build-system topic, and that is accurate rather than lazy: the primary language GitHub detected is TeX, and the tree contains `book/`, `netlify.toml`, a `Vagrantfile` and a `tests/` directory rather than an application. `book/` is where the chapters live and `netlify.toml` is what turns them into the site at book.the-turing-way.org. The scope of the audience is stated plainly in the README. Students, researchers, software engineers, project leaders and funding teams are all named as stakeholders, with the stated goal being to give people what they need at the start of a project so that reproduction is easy at the end. ## CI that greps for placeholder text and Latin phrases The build badge row in the README is unusual enough to be worth reading closely. There are four separate checks: the Netlify build itself, a Check for Latin Phrases workflow, a TestFileSizes workflow, and a workflow that greps for stock placeholder prose. A software project does not usually test for filler prose. A handbook with six hundred open issues and several hundred contributors does, because the failure mode is a chapter left half-translated or a paragraph that still reads like a template. TestFileSizes is doing something similar for file weight. In a repository where images are committed alongside Markdown and TeX, a file that suddenly jumps in size is usually an accidental binary drop rather than an intended diagram, and a size assertion catches that cheaply in CI where a reviewer's eye does not. The third check is not in the badge row but is in the tree: `lychee.toml`, the configuration file for a link checker. A book full of external references rots silently, and a scheduled link check is the only way to notice. It is a small file with a large effect on whether the references are trustworthy, and it is the piece of infrastructure that most distinguishes a maintained handbook from a PDF someone uploaded once. There is a `CODEOWNERS` file too, which matters more in a project with this many contributors than in a small codebase, because it is the mechanism that keeps whole chapters from stalling while their owner is on holiday. ## Nine translations, and one link that points somewhere else The second line of the README lists translations in alphabetical order: Chinese, Dutch, French, German, Indonesian, Italian, Korean, Portuguese and Spanish. Eight of the nine links resolve into a `README-translated/` directory at the repository root. The French one does not. It points at `README-French.md` in the repository root, with no directory prefix, while every neighbouring entry is written as `README-translated/README-.md`. The tree lists `README-translated/` as a root entry and does not list a root-level `README-French.md`. So the French link is inconsistent with the pattern the other eight follow, and the repository listing gives no sign of the file it names sitting at the top level. Two facts, both checkable: the README's own convention is the `README-translated/` prefix, and the tree exposes only that directory. Whether the French translation is genuinely misplaced or simply lives somewhere the tree does not surface is not something the repository settles for you, and the handbook's own translation guidelines, linked from the README, are where a contributor would find out where a file is supposed to go. That this is the single blemish in an otherwise meticulous link block tells you something about the maintenance regime. Nine languages, four CI checks and a link checker will not catch a path typo introduced in the README itself, because CI checks files, not the prose describing them. ## Citation runs through Zenodo, not through the releases tab The README's cite row gives a DOI badge pointing at `10.5281/zenodo.3233853`. That is a Zenodo concept identifier, minted when the project first archived, and it is the citable anchor. The tree backs this with two files: `.zenodo.json`, which is Zenodo's metadata configuration, and `CITATION.cff`, the Citation File Format document that tooling reads to produce a formatted citation. The releases tab tells a different story. The three releases present carry no tag names, and their bodies are publication announcements that link to a specific edition rather than to a diff. The two older ones link into `alan-turing-institute/the-turing-way`, which is a previous organization name for the repository, while the project now lives at `the-turing-way/the-turing-way`. The release bodies are therefore archival records pointing at where the project used to be, which is the same stale-path pattern you see in badges of older projects that have been renamed. The newest release announcement is dated 2025-04-14, while the last push to the repository was 2026-09-21. For a book that is expected, and it draws a useful distinction: the source moves continuously while the citable edition changes occasionally. If you need to cite a specific version of the text, the DOI plus the edition is the pair to record, and a commit hash from the default branch is not a substitute for either. ## Governance documents in the root, not just in the handbook Some of the most consequential content in this repository is not in the book. `ways_of_working.md` describes how the project operates, `GOVERNANCE_ROLES.md` names roles and who holds them, `ACCESSIBILITY.md` sets accessibility expectations, and `CODE_OF_CONDUCT.md` is present as well. Having those at the repository root rather than buried in the published site means they are versioned, diffable and reviewable in the same pull request stream as the chapters. That choice has a cost worth naming. A reader who wants to know how decisions get made has to know which file to open, and the README does not index these four documents for you. What it does do is link `CONTRIBUTING.md` in the Project row of its table, which is the file a new contributor actually wants, and point at the handbook's own translation page for localization work. `tests/` is also present at the root rather than inside `book/`, which suggests the checks described by the badges are implemented as repository-level tests over the whole tree rather than as part of the site build. For a fork, that is a detail with practical consequences: if you fork the project to run an internal edition, you inherit the placeholder-text and Latin-phrase checks, which will then be applied to whatever text you add. ## What the license field says and what the LICENSE file says GitHub reports the license for this repository as NOASSERTION, which is the value you get when a machine classifier cannot map the license text to a known identifier. The repository nonetheless contains a `LICENSE.md` at its root, and the README explicitly tells readers they can re-use all materials and points them at that file for the terms. So there are two facts here that a script and a human will report differently: automated license detection returns no assertion, and the project states in prose that the materials are reusable under terms set out in the file. That gap is worth understanding rather than worrying about. NOASSERTION is common on repositories whose license is expressed in a custom or composite form, and this one may well be exactly that, given that a book with illustrations, translations and community contributions does not reduce neatly to one OSI identifier. What NOASSERTION does mean is that tooling which gates on SPDX identifiers will not know what to do with it, so if your organization has automated license scanning, expect a manual review here. The advice that follows from this is narrow and practical: read `LICENSE.md` if you plan to reuse a chapter or an illustration, and do not infer restrictions from the absence of a detected identifier any more than you infer permission from it. ## Conclusion The Turing Way is unusual in that the artifact and the process are the same thing: a book whose chapters are pull requests, whose translations are contributed the same way new chapters are, and whose CI refuses placeholder prose. Read the online edition for the content, then read `ways_of_working.md` and `GOVERNANCE_ROLES.md` in the repository if you intend to contribute, because those two files explain decisions the handbook itself only asserts. Before reusing any figure or chapter, check `LICENSE.md` directly rather than trusting the license field GitHub displays, and check the Zenodo DOI rather than a release tag, since the releases in this repository are publication snapshots and the DOI is what the citation file points at. ## FAQ ### What is The Turing Way and who is it for? It is a handbook for reproducible, ethical and collaborative data science, published as an open book at book.the-turing-way.org and maintained as a public repository. The README names students, researchers, software engineers, project leaders and funding teams as the intended readers, with the goal of supplying what a project needs at its start so it can be reproduced at its end. ### How do I cite a specific version of The Turing Way? Use the Zenodo DOI in the README's cite row, `10.5281/zenodo.3233853`, together with the edition you read. The repository also carries a `CITATION.cff` file and a `.zenodo.json` configuration, which are the machine-readable sources a citation tool should prefer. Releases in the repository are publication snapshots and carry no tag names, so they are a weaker anchor than the DOI. ### Can I translate The Turing Way into my own language? The README lists existing translations in Chinese, Dutch, French, German, Indonesian, Italian, Korean, Portuguese and Spanish, and invites new ones, pointing at the handbook's translation page for the process. Translations live under a translated-README directory, so a new language adds a file there and follows the naming pattern the other eight entries use. ### What license applies to the text and illustrations? The README says all materials can be re-used and directs readers to a `LICENSE.md` file at the repository root. GitHub's own license detection reports NOASSERTION for the repository, so automated license scanners will need a manual answer here rather than an identifier they can match. ## Sources - [Issues](https://github.com/the-turing-way/the-turing-way/issues) - [Project website](https://book.the-turing-way.org/) - [README](https://github.com/the-turing-way/the-turing-way/blob/main/README.md) - [Releases](https://github.com/the-turing-way/the-turing-way/releases) - [the-turing-way/the-turing-way on GitHub](https://github.com/the-turing-way/the-turing-way) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/the-turing-way-the-turing-way