The Rust Organization in 2021

When I broke down the kinds of things I want Rust to do in 2021, they fell into two main categories. One was the nuts and bolts of language and compiler features that Rust programmers use every day. The other was organizational: the meta about how those features get implemented.

Those organizational aspects are vitally important to how Rust develops over time, and I think they deserve their own post. So here it is!


The most important thing I’d like to see in 2021 is the establishment of the Rust Foundation. We’ve been talking about it for some time, and the core team has signaled that it’s time to act.

There isn’t much to say here that hasn’t been said in those posts already. We should start with the basics: trademarks and infrastructure. It’ll also be useful for funding things like the Rust All Hands.

I think we’ll eventually want the Rust Foundation to hire people to work on Rust, but probably not next year. I have more to say about this, but I can’t fit it all in this post, so I’m saving it for a future post.

Collaborative Summary Docs

I am a big fan of the collaborative summary document and would like to see us use it more.

Recently I was involved in the drafting of an RFC for the Stream trait.1 There were a number of “offshoot” discussions about future additions that happened while refining the draft, most of which are documented across a set of pull request comments and lang team meeting notes.

The RFC itself now attempts to summarize the future work and various concerns here. But I’m a bit dubious of this approach for a couple reasons:

Taking advantage of backpressure

Rust teams are often overloaded with RFCs or ideas for RFCs. People’s focus and attention are limited relative to the number of ideas and RFCs; this creates backpressure. There’s been much discussion around how to better model this backpressue explicitly and how to streamline lightweight changes.

Collaborative summary documents are a great way of handling backpressure situations. Anyone can make them, anyone can contribute to them, and anyone can get up to speed by reading them.2 A team member’s attention isn’t needed at the start. As team members are ready to give their attention, the problem space should already be mapped out for them.3

A doc for the ages

The Rust RFCs repo has an enormous number of RFCs that were closed or postponed as something we might want to do in the future. Many of them have quite a large history of discussion in Github comments, plus discussion that happened in irlo, Zulip, or elsewhere.

There’s very little chance that someone who was not around at the time of this discussion will be able to map out the problem space that was explored in these long discussions. Again, we’re relying on the context tucked away in certain people’s heads. And this is even more of a problem as people leave the project – whether due to burnout, changing life circumstances, or other reasons.

I’d like to see collaborative summary documents that can stick around for years, accepting improvements and additions over time, until they’re ready to be made into one or more RFCs. I think we should have a central repository4 of them somewhere that anyone can add to, similar to the rfcs repo but with a much lower barrier to entry.

In fact, this seems so valuable that we may want to consider making these docs a prerequisite to the RFC process. They can be a great companion doc to an RFC, going into greater detail about paths not taken and future jumping off points.

Let’s start now!

We don’t need to wait for new ideas to start making collaborative summary docs. It’d be incredibly valuable, in fact, for someone to dig through an old discussion and start writing them for ideas that have been postponed. Having a definitive doc on the state of an idea and the problem space it lives in is valuable to Rust organization members and users alike.

Streamline contributions

I think contributing to Rust should be easier. This is an evergreen statement, but that doesn’t make it less true. There’s been a lot of great work on this front recently, and I’d like us to keep up the momentum.

One specific improvement I’d like to see is making sure that pull requests get reviews in a timely manner. All too often I see pull requests – often from first- or second-time contributors – that end up being ignored for weeks or months. The new contributor is faced with the choice of endlessly “nagging” their reviewers, or silently accepting their fate.

Needless to say, this is a really bad experience. I will say that the Rust project is better about this than many other open source projects, and we have a great culture to thank for that.

But culture can’t remove fundamental constraints. The fact is, we all get busy and sometimes we just have too many things going on. We may not even realize someone is waiting on us. I’m certainly no exception, and have been guilty of this myself as a reviewer. But while we’re busy, there might be someone else who’s just as qualified to review a change.

The Rust project has been very successful at writing Github bots to automate bits of our workflow, and I think that’s what we should do here. Let’s make highfive re-assign reviewers after a lack of activity, and nagremind them on the contributor’s behalf!

Addendum: Growing more reviewers

After I first published this post, DPC told me that this is indeed a priority for the triage working group right now, and that it can be difficult to strike a balance between making the contributor experience great and being respectful of reviewers.

That points to a different problem: We need more reviewers. No one working in the compiler knows the entire codebase, which means there are often only a couple people who can review a particular piece of code.

Let’s empower more people to review compiler contributions. I think we can make progress on this by making it an explicit goal in each working group.

One thing that I think tends to hold us back here (consciously or not) is that being able to r+ changes is a fairly big responsibility, and all-or-nothing. We can’t give someone reviewer’s rights for only certain files. Maybe we should look into doing that. Or maybe we can get away with a lighter-weight approach of giving new reviewers broad “areas of ownership” and guidelines for when to ask for a second review.

Another possibility is creating a group of “proto-reviewers” that review a change using Github’s review interface (anyone can already do that), applying consistent standards throughout the codebase, and only have global approvers do a final sign-off.


Year after year, I continue to be impressed with the progress Rust makes. The thoughtfulness, care, and passion of everyone involved is a force to be reckoned with. I think 2021 will be no different, and I’m looking forward another great year for the Rust organization.

Thanks to Didrik Nordstrom, Adam Perry, Nika Layzell, and Manish Goregaokar for reviewing drafts of this post.

  1. I’d like to give a big shoutout to nellshamrell, who drove this process and did an amazing job of it. My critique of the overall process certainly isn’t a criticism of her (or anyone’s) work. ↩︎

  2. At least, in theory. We have a long history of continually refining things that work in theory to make them work in practice (like the RFC process), and I see this as just another step in that direction. ↩︎

  3. Team members often have context on one area of the problem space that isn’t well known. I think team members should get involved early on in commenting on the collaborative summary docs that are most relevant to them. Crucially, this is a lightweight commitment to help define the problem and solution spaces, not a commitment to help get the feature accepted. ↩︎

  4. Maybe an mdbook, maybe the README of a standalone repo somewhere, or maybe a wiki. The important thing is that it’s easy to contribute to and that there are maintainers to help keep it organized. ↩︎