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!

Foundation

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.¹ 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:

• Detailed discussions about future features don’t belong in the RFC, so we’re trying to thread the needle of summarizing the state of the discussion at a high level while trying not to miss technical details that could be important.
• There’s no central, discoverable, authoritative place for the discussion to go. If we want to pick up the discussion in the future, we’re relying on individuals who remember all the important points and can dig up the context when needed. When important details are scattered across people’s memories, it can slow down progress over time.

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.² 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.³

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 repository⁴ 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.

Conclusion

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.