A few things have been happening across the Ubuntu docs landscape that are worth an update: release notes get a new home, hardware support docs consolidate, Zig makes its debut in the developer docs, llms.txt lands, and a couple of quality-of-life improvements round things off.
Ubuntu release notes: new home on RTD
The Ubuntu release notes have moved. They’re now published at documentation.ubuntu.com/release-notes — a proper Sphinx/Read the Docs site backed by a GitHub repo, rather than a Discourse posts.
The move brings all the usual benefits of a versioned, GitHub-managed docs source: structured navigation across releases, better search, consistent formatting, and a lower barrier for contributions. Looking for the 26.04 LTS notes, or the point-release notes for 22.04? They’re now where you’d expect them, neatly organized alongside the release schedule pages.
And the RN for 26.10 have a skeleton structure at 26.10 (Stonking Stingray). Speaking of which, check out the How to contribute to Ubuntu release notes article to read about the new flow.
Ubuntu hardware support docs: a unified home
Two previously separate documentation sets -— the RISC-V Image Cookbook and the Ubuntu Boards docs -— have been merged into a single Ubuntu hardware support documentation site.
The combined set covers installing Ubuntu on a wide range of non-PC hardware (Raspberry Pi, RISC-V boards, and more), as well as building custom Ubuntu images for hardware that lacks out-of-the-box support. The intended audience spans hardware engineers, system integrators, and developers who need Ubuntu running where a standard installation won’t cut it.
Merging the two sets eliminates a split that never made a whole lot of sense from the reader’s perspective. If you’re working with a StarFive board, you care about both flashing images and building them. Having it all in one place makes for a much more coherent experience.
Zig joins Ubuntu for developers
The Ubuntu for developers docs now cover the Zig toolchain. Three articles have been added: a how-to guide on setting up the Zig development environment, a tutorial on building and testing Zig programs, and a reference page on available Zig versions across Ubuntu releases.
Zig is a nice addition to a docs set that already covers Python, Go, Rust, GCC, Clang, .NET, and Java. If you’re targeting Ubuntu as your Zig development platform, you now have a proper place to start.
llms.txt for Ubuntu docs
Following the investigation I wrote up in llms.txt for Canonical docs, the llms.txt standard is going to be implemented across Ubuntu (and other Canonical) documentation sets. The implementation uses the sphinx-llm extension, which generates both the llms.txt link index and per-page Markdown files as a natural byproduct of the Sphinx build.
The upshot: if you’re using an AI coding assistant and want it to actually understand the Ubuntu docs relevant to your task, you can point it to the relevant llms.txt (or llms-full.txt) and have it work from a clean, fluff-free Markdown version of the content. Way more efficient than feeding it raw HTML. Try also the PoC MCP server I hacked together specifically for serving our docs to AI coding clients and/or agents: docshub.
The Ubuntu for Developers docs, for instance, are available at documentation.ubuntu.com/ubuntu-for-developers/llms.txt.
A “webring” for Ubuntu docs
A small but handy addition: Ubuntu docs sets are now interlinked via a shared navigation element that appears across participating docs sites. It’s a drop-down menu in the top site header called, ehm, Ubuntu documentation. The idea is loosely analogous to an old-school web ring — a way for users landing on any one Ubuntu docs site to discover the others without having to go hunting. See it in action on the Ubuntu release notes site, for example.
The implementation lives in each docs site’s Sphinx configuration and a shared header template; the PR in ubuntu-release-notes that kicked things off shows what this looks like in practice. As more Ubuntu docs sites adopt the pattern, the network of cross-links will grow. It’s a small thing, but Ubuntu docs are spread across enough separate sites that a consistent navigation aid between them genuinely helps.
Ubuntu Project docs: maintenance matters
Two things are worth noting on the maintenance side of the Ubuntu Project docs.
First, a formal triage policy and process is now in place. The key points: specialist teams (MIR, SRU, governance groups) retain ownership of their own pages via CODEOWNERS; Ubuntu Core Devs and above get maintainer rights by default; and all Ubuntu engineers are expected to participate in triage. Auto-labeling and auto-close rules for spam and junk are already live (thank you, Sally), with an agent-based review workflow and a formatting auto-fixer in the works.
Second, a Python script and GitHub Actions workflow (to be merged soon) will send a weekly status report on open issues and pull requests — posted to both (internal Canonical) Mattermost and (Public Ubuntu) Matrix (pending approval from ubuntu-devel). The goal is simply to keep the queue visible. Nothing fancy, but these gentle nudges tend to work.