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: 19th February 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 calendars Managing 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 membership
I 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 my On Compiler Team Membership series (Part I and Part II).
In February 2023, we wrote an RFC changing the team’s structure to address this feedback which has been shared with the compiler team.
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.
In January 2023, 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.
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.
Regularly check-in with compiler team members
Conferences are great for being able to chat with team members and get a sense of how they’re feeling about the team and the project, but I ought to be more pro-active about checking-in with everyone, or having a office hours or something like that.
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.
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.
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.
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!
Next up - these are my plans as an individual contributor for things that I’d like to get around to working on:
I’ve been working on this on-and-off for a while and want to see it through to completion. Diagnostic translation is adding support for the compiler’s error messages being emitted in different languages, like Chinese. There’s a lot of compiler infrastructure and refactoring necessary to do this and working out how to implement this in a way that’s nice-to-use is the tricky part.
Nothing else.. yet!
I’d like to just help fix bugs, do refactoring and help out around the compiler for a while after finishing my ongoing projects.
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.