Rust Program Manager Updates

RustConf 2026

Shortly after joining the Foundation full time, I attended two conferences: RustConf and Kangrejos. Both events were fantastic and at the opposite ends of the conference spectrum. I’d like to highlight a few moments from the point of view of a Rust Program Manager. This first post is about RustConf and the follow-up post will be about Kangrejos.

RustConf 2026

This was my first time at RustConf and my first time representing both the Rust Project and the Rust Foundation as I had just started my new position at the Foundation. It ran from 8-11 September with the first day dedicated to workshops and the Rust Teams Health Summit and was closed out by an UnConference. This is a large conference with hundreds of attendees, multiple tracks, breakout sessions and booths. I’m going to focus on parts of the conference that stood out the most for me.

Team Health Summit

The Rust Project members (i.e. the community of people building Rust) got together to discuss the overall health of the Project and ideas on how to improve it. Most of the attendees were team leads, but we had several non-lead members as well as a few Foundation folks present. I got to wear multiple hats during the summit: Program Manager for the Rust Project, Project Goals Team Lead, and Rust Foundation staff member.

We started with a representative from each team talking about the team’s size, struggles and needs. They described how the team works, what their processes are, and when a lead was present, what their responsibilities were. This took a good chunk of the morning and showed how diverse the teams are in how they work and organise. Here’s the bit I shared about leading the Project Goals team:

Project Goals are a way to drive changes to Rust. A new feature will often need buy-in and commitment from multiple teams (for example, a new syntax proposal might need input from the Language team on the semantics, Library team for the underlying traits, Style team for how it should be formatted as well as implementations in the compiler and rustfmt).

Even established Project members don’t always know whom to talk to and what processes to follow, but for anyone from the outside, this is really difficult to figure out. Project Goals help solve this: you write a goal proposal and commit to doing the work and writing regular updates. The relevant teams will review it and if they accept it, they’ll commit to the work you need from them (this can be code reviews, design meetings, mentoring, etc.).

Getting a goal accepted means you know the Project likes your proposal and you’re free to proceed.

The Goals team facilitates all this. We’re a small team with 2-3 active members and a few more following along and helping out. We help people get started, walk them through the various processes, look at the upcoming proposals and work with the Project to identify the goal’s needs and bring the right people in. We also keep track of all the goals throughout their lifecycle and continuously try to improve the tooling and processes.

Goals can also request funding and we make sure that’s properly communicated.

I received a lot of feedback from the members around the Goals process. As we are building out this new way of working we have worked to improve our processes and that has meant a lot change has happened in a short period of time. We’ve moved from a six month to a yearly goal tracking period, introduced roadmaps, and added the ability to add goals throughout the year. There’s an impression that the program is changing too much and that makes teams wary of relying on it which is great to know so we can work to build confidence with other teams in what we are doing and why we are doing it this way.

On the positive side, they highlighted that this has been the most successful experiment for cross-team coordination and that it’s valuable for people outside of the Project who want to drive changes, but don’t know where to start.

We spent the rest of the day discussing communication between teams, stability beyond the language and we closed the day talking about accountability mechanisms in the Project.

Here are some highlights:

• Cross team collaboration: right now, teams don’t necessarily know if their work requires input from another team or how to go about getting that. This is even harder for people outside of the Project. We discussed having a central intake process led by the Goals team and leads that could route things to the right places and help to prioritise them across the Project.
• Stability: Rust (the language) and rustc (the compiler) have stability guarantees in place, but how do these work for rustdoc, clippy, rustfmt, etc.? We went over the stability situation for each tool and service. There’s a lot that’s not documented and we agreed that teams should write specs for things such as crates.io API and Cargo interfaces.
• Accountability: A lot of the non-technical processes are not documented or even decided in many teams: how members join, how are leads selected, how are people removed, what are leads supposed to do. Without this, it’s hard to hold leads accountable. This is part of what the Comprehensibility team is looking to document and help bring closer together.

In my experience, these sorts of differences in how teams operate are common in large open source projects and it is always incredibly useful to bring people together and talk through these in person.

Rust in CPython Talk

At the beginning of this year, the Project started regular meetings with a few Python engineers interested in bringing Rust to their interpreter (cpython). We helped the team move along, answered their questions and discussed ongoing and planned work that might help them. The team wrote a proof of concept that uses Cargo to build a module in Rust and make it available in Python and they’re now designing an API for internal modules to use.

I gave an update on this collaboration and the progress they made. You can watch it here:

Interviews

Just like last year, the Content team conducted interviews on site and as part of that, I’ve interviewed Rakhi Sharma about her work on Servo, the web rendering engine written in Rust (and originally created at Mozilla) and how she got there. Rakhi’s been wonderful and I can’t wait for everyone to listen to the interview once it’s out.

The Hallway Track

I’ve spent a significant portion of my time there talking to people. I loved the fact that the Project and Foundation tables were right next to each other. This worked out really well. The attendees had one obvious place to go and depending on what they wanted to talk about, we could just direct them to the right person whether it be a Foundation representative or someone building Rust itself.

I ran into Ben Striegel (bstrie) — a co-host of the Rustacean Station podcast. It’s a community project for hosting and distributing Rust podcasts. They record their own episodes, but they also accept recordings from other people in the community. The Content team’s been thinking about making our interviews and changelogs available in a podcast form as well, so Ben and I talked about posting them on the Rustacean Station. He was interested and this is something I’ll be following up on.

A lot of what I ended up doing there was paying attention to folks who were standing a couple of metres away from the tables, unsure how to proceed. I would walk up to them, we’d start chatting and either keep at it, or I would direct them to someone who was going to help them more directly (e.g. someone working on the specific area of the compiler they were interested in).

Being there was fantastic. I got to meet my Foundation colleagues in person and a lot of the Project people I only saw over Jitsi and some whose faces I’ve never seen before.

If I had one wish, I’d love for there to be a single table for both the Foundation and the Project next time.

Overall it was an excellent experience and I look forward to RustConf 2027!