rust-lang/this-week-in-rust: the repository behind the Rust newsletter

What the this-week-in-rust repository actually holds

The repository is the source of truth for this-week-in-rust.org, the long-running weekly newsletter about the Rust language and its community. It is not a library and it is not a CLI. It is a content repository plus a Pelican site: Markdown drafts, a theme, plugins, and the configuration that turns them into a published issue. The README states that the content is made available under CC-BY-SA, while the code carries an MIT licence attributed to Ember Arlynx. Those two licences cover different things in the same tree, which matters if you plan to reuse anything.

The audience is narrow and specific. It is the editors listed in the README, the language reviewers who check translated content in Japanese, Spanish, Portuguese and Chinese, and anyone in the Rust community who wants a link, event or call for participation to appear in the next issue. If you are not in one of those groups, the repository is still readable as an example of an editorial workflow expressed as files.

Drafts, sections and the pull request path into an issue

The mechanism is deliberately low-tech. The README says the next issue lives in the `drafts/` folder (the repository listing shows `draft/`, and the README text uses `drafts/`), and that contributors propose content by opening a pull request that edits the relevant section of that draft. There is no submission form, no database and no queue service. The pull request is the queue.

Once merged, content flows through Pelican. The `content/` directory holds published issues, `themes/` and `plugins/` supply rendering, and `pelicanconf.py` is the configuration entry point. The `requirements.txt` pins the toolchain: `pelican==4.7.1`, `Markdown==3.7`, `jinja2==3.1.6`, `libsass==0.21.0`, `pelican-webassets==2.0.0` and `pelican-search==1.0.1`. The presence of `pelican-search` means the built site carries a client-side search index, and `pelican-webassets` plus `libsass` means asset bundling and stylesheet compilation happen at build time. That is a heavier build than plain Markdown to HTML, and it is the part most likely to break on a machine with a different Python or system library setup.

Editorial sorting is also part of the mechanism. The README lists fixed community sub-categories such as Official, Foundation, Project/Tooling Updates, Newsletters, Research, Observations/Thoughts, Rust Walkthroughs and Miscellaneous, and says editors will sort links into them. Contributors do not get to pick a category freely; the editors reassign.

Installing the site and building a local copy

The repository ships a `requirements.txt` and a `run.sh` at the top level, which is the intended path. The README does not spell out an install sequence in the text available here, so the commands below follow the standard virtual environment flow against the pinned file, plus the `run.sh` script that the repository layout shows.

Create an isolated environment and install the pinned dependencies:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

After this, `pip list` should show `pelican 4.7.1` and the other pinned versions. If `libsass` fails to build, the problem is a missing system compiler rather than a Python version conflict, since the pin is explicit.

Then build or serve the site using the script the repository provides:

./run.sh

What `run.sh` does exactly is not documented in the README, so read the script before running it. It is the only entry point the layout offers besides invoking Pelican directly against `pelicanconf.py`.

For a content contribution rather than a site build, the first real use is smaller: open the file for the current issue under `draft/`, add your link under the correct heading, and open a pull request. The README notes that PRs for the next issue are accepted against that draft.

Where this-week-in-rust pushes back: the submission rules

The README is unusually explicit about what it rejects, and that is the most useful part of the repository for a prospective contributor. Paywalled content is out, including Medium's members-only mechanism. Anything that requires an email address or other information before you can read it is out. Duplicates of recent posts are out even when the wording changes. Rants and posts that degrade a part of the community are out; the README asks instead for something explaining how you would make it better.

The LLM policy is a real constraint rather than a formality. The README says the editors do not take a position on whether you use an LLM, but that they care whether articles were written by people, and that LLM-written submissions should disclose LLM authorship in the article. The stated reason is community: with no human author there is no one to learn from feedback and no peer for the reader to connect with.

One section has closed to pull requests entirely. Project/Tooling Updates no longer accepts PR submissions; the README points to issue 8575 and says editors monitor r/rust and will consider links posted there. If your submission is a tooling release, the pull request path is the wrong tool, and the correct move is a post on r/rust that follows that community's rules. Events have their own guidance, with a preference for free events and a general exclusion of commercial offerings except conferences and similar educational offerings.

How This Week in Rust differs from a personal link blog

The closest alternative in practice is a personal Rust link blog or a link aggregator like r/rust, and the difference is editorial rather than technical. A personal blog publishes whatever its author chooses, with no fixed cadence and no review. r/rust accepts posts at any time and ranks them by votes, so visibility depends on the moment you post. This Week in Rust is a scheduled, edited digest: a fixed set of sections, editors who sort links into categories, language reviewers for non-English content, and a link style guide that requires the link text to match the page title, the most canonical URL, and no tracking parameters such as `utm_source` or `utm_campaign`.

That editorial layer is the product. It also means the repository is a poor fit for anyone who wants to publish immediately. You are proposing into a draft that editors will revise, and in some sections you are no longer proposing at all.

A second difference is the prefix convention. Links carry bracketed markers to the left: `[video]`, `[audio]`, `[series]`, and two-letter language codes like `[ZH]`, `[ES]` and `[FR]` for non-English content. A general-purpose blog has no equivalent, and a contributor who ignores the convention creates work for the editors.

Maintenance, licences and what to check before contributing

The repository is not archived, and the last push was on 2026-09-24, which is recent. That tells you the content pipeline is live; it does not tell you how quickly a given pull request will be reviewed. The README names eleven current editors, five language reviewers and eight alumni editors, which is a volunteer roster rather than a staffing guarantee.

Upgrade cost is mostly the pinned dependency set. `pelican==4.7.1` and `markupsafe==2.0.1` are exact pins, so moving to a newer Pelican means testing the theme, the `pelican-webassets` and `pelican-search` plugins, and the Sass compilation together. There is no release history in the repository, so the practical upgrade signal is the last push date and the state of `requirements.txt`, not a changelog.

On licensing, the README separates the two halves of the tree: content under CC-BY-SA and code under MIT. Reusing the theme and plugins is a different question from republishing newsletter text, and the README does not discuss attribution mechanics for either. That is a question for someone qualified to answer it, not something to infer from the file names.

Editorial conclusion

Adopt this repository if you are contributing a link, an event listing or a Call for Participation to the next issue, or if you want a local Pelican build of the site to check rendering before a PR. Do not adopt it as a general static site starter: the value is the content pipeline and the editorial rules, not the theme. Before opening a PR, read the link style guidelines in the README, confirm the draft file for the current issue under draft/, and check whether your item belongs in a section that still accepts pull requests, since Project/Tooling Updates no longer does.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. rust-lang/this-week-in-rust on GitHub