Priorities, plans and backlogs
An evergreen list of my priorities and planned work in the Rust project..
Hello! If this is your first time reading one of my newsletters, I’m as @davidtwco on GitHub or Zulip or anywhere else and I currently co-lead the Rust compiler team - this is where I share some of my thoughts and half-baked ideas about the project and whatever else I feel like. If you missed my previous posts, you can find them below:
You can also subscribe and get an email when I write something (very infrequent), so feel free to do that if you’re so inclined:
Last Updated: 1st November 2024
I expect that most contributors have a list tucked away somewhere in a notebook or app of things they’d like to work on within the Rust project, I certainly do. Especially now that I’m co-leading the compiler team, I thought it would be beneficial to share my to-do list so that team members and anyone with an interest can see what work I’m thinking about.
Before I get into the list itself, some caveats: I’m only documenting my intentions as-of-last-update in this post. It’s entirely possible that I don’t get around to things on this list, or decide to drop an item from the list or change its priority. Just because an item is on my list, that doesn’t mean it’s absolutely confirmed to happen, it’ll always depend on feedback from team members and the Rust community. These items aren’t for 2024 or any specific year, the list will be updated over time.
I don’t expect that I have an exclusive claim on any of these ideas or to-do items, if you want to nab one and take the lead on it - go ahead. Send me a message somewhere if you’d like to chat about it and see what I’ve been thinking.
First up - these are my priorities as compiler team co-lead. If you’re a member of the compiler team, feel free to reach out and chat about these or add to this queue. The priority of these is based on what I think is most important to the team - so let me know!
✓
Improve team calendarsManaging our team’s calendar through Google Calendar isn’t great because most of the team don’t have access to it - we should generate our calendars from a GitHub repository that we manage using our usual workflows and tooling.✓ Re-visit compiler team membershipI got a lot of feedback from team members during EuroRust 2023 that our current team membership structure wasn’t serving us as well as it could be. I’ve written about this in myOn Compiler Team Membershipseries (Part IandPart II).
Feb 2024: We wrote an RFC changing the team’s structure to address this feedback which has been shared with the compiler team.Mar 2024:Our RFC for this has been postedand is undergoing public review.Sep 2024:Our RFC was merged and we’ve been working on implementing these changes and that should be done soon.
Oct 2024: We’veimplemented the RFCandpublished a blog post.Improve our team documentation
We’ve got some documentation on the compiler team’s website and some in the Forge. Working groups have their own repositories and those are in various states of maintenance - we should consolidate this in one place and structure it well.
Improve compiler team review queue
Another area that I’ve received a lot of feedback about is our review queue (it’s long!) and we’ve not got as many team members in the rotation as we need to keep the workload manageable for everyone. It might also make sense to change the way that the review assignment works. There is some overlap with the idea of responsibilities in the earlier Re-visit compiler team membership item.
Jan 2024: We discussed the review queue and more members have joined the queue, and I wrote On the compiler team’s review queue looking at the changes in the review queue over time.
Establish a living roadmap for the team
It’s hard to know what’s going on in an open source project, and Rust is no different, but there’s a handful of reasons why we want to have better insight into this, see my previous writing on this.
Mar 2024: Since my previous writing, there has been discussions around a “Project Goals” process which could address some of what my post was thinking about.Review target compliance against our target tier policy
We’ve got lots of targets but lots of them predate our target tier policy, so not every target has a list of maintainers, which we require. There also isn’t consistent documentation across our targets, which we could improve.
Mar 2024: Nilstrieb has been doing excellent work to build infrastructure to support better target documentation.Improve final comment periods (FCPs)
FCPs are when everyone in the team signs-off on a change, which makes sense, but doesn’t scale very well. We end up with some diffusion of responsibility where everyone thinks everyone else is going to do the detailed review and just does a sanity-check (fortunately someone normally is familiar with the relevant issue and does do a thorough review). There are a handful of possibilities here, which we should explore. There is some overlap with the idea of responsibilities in the earlier Re-visit compiler team membership item.
Mar 2024: We partially address this in our compiler team restructuring RFC.Revisit the triage meeting agenda
Our triage meeting agenda has parts that are very useful - discussing nominated issues and reviewing backport nominations are really important. Other parts of the agenda have limited utility to everyone in the meeting. We should revisit our goals for the meeting and make sure that it is serving us well. There is some overlap with the idea of responsibilities in the earlier Re-visit compiler team membership item.
Write the external dependency timelines policy
We’ve had steering meetings on our policy for on long we wait to land changes to the compiler which depend on support in external tooling - I just need to get around to writing it up.
Document ongoing experiments within the compiler
There are lots of ongoing experimentation in the compiler - it would be good to have a list of what these are so that we can re-visit them and make sure that we want to continue with them.
Re-establish the expert map
We used to have an expert map which documented who had expertise in which areas of the compiler, but it would get out-of-date a lot and we never really worked out how to keep it updated - we should re-introduce this in a way which is sustainable.
Review rustc’s usage of unstable features
We use lots of unstable features in the compiler, which is great for dogfooding, but we should check whether any of these could be stabilised, especially for library features where the libs team might just be waiting for someone to ask for stabilisation.
Improve the discoverability of our Zulip streams
We’ve got lots of Zulip streams, but we don’t list them anywhere. If you don’t go looking for them in Zulip, then you might be missing interesting conversations - we discovered that this was the case for some team members at EuroRust, so we should do a better job at documenting these.
Require developer guide updates when features are stabilised
One of the biggest improvements to the contributor experience of the last few years is the developer guide, and it’s come a long way, so we should think about requiring updates to it before stabilising features.
Consider addition to target tier policy to limit targets that are EOL’d by their vendor to tier three
I can’t remember where I saw this suggested but I think it’s a good idea - there probably should be limits on how much stability and support we provide for a target that the vendor doesn’t support anymore.
Establish more-detailed stability policy for compiler flags
This was raised in a steering meeting and it’s a good idea that’s worth following up on.
Resolve licensing issues
There are a handful of edge cases in the project repositories where the licensing isn’t clear - contribute to getting these sorted.
Improve issue triage message and procedure
Some team members have shared with me some ideas about how our issue triage messages and procedure could be more useful: closing issues/pull requests for the sake of closing them isn’t that useful; pings can produce lots of notification noise; there’s no distinction between a one-off contributor and team member; some of this work could be automated; and there are more useful things that triage could try and help with, like getting reproduction steps, checking for regressions, or doing bisections.
Encourage and create a space for more social interaction between compiler team members
Social relationships between team members are important and it’s something that is always remarked on when we get together at conferences, but we don’t have any space for this in the project itself, which can leave some contributors a bit isolated if they aren’t aware of the handful of places where some contributors gather.
Review attributes in rustc_attrs and check if any of them could be re-usable and general purpose
There are lots of attributes in the rustc_attrs feature and some of them might be able to be made re-usable and general purpose - we should have a look!
✓
Set up office hours for team members
It would be useful for to have a regular block of time that compiler team members can use to chat with me about any issues they’re having or anything else related to the project.
As an individual contributor, most of my work will be related to Arm’s priorities for Rust. I’ll try to keep this list updated every few weeks or so, I’ll update the date at the top of this post when I revisit this list.