On compiler team membership (part I)
How well is our team structure serving us?
I had a really fun time at EuroRust 2023 - the talks were interesting and the venue was great. I think this is was only my third Rust conference and I’ve learnt that - for me, at least - the point of going to a conference like EuroRust isn’t really to attend the talks, the point is to meet up with my colleagues in the compiler team and broader Rust project. EuroRust was great for that - a bunch of the compiler team managed to make their way to Brussels for those few days. I got to meet a few members of the team that I hadn't met before and chat with everyone about what they thought was and wasn’t working with the compiler team. I took a lot of notes and have a lot of ideas for how we might work and organise ourselves differently.
Rust’s compiler team currently has a two-tiered structure - after contributing for a while, you can become a “compiler team contributor”, and a while after that, you might become a “compiler team member”.
A brief history of compiler team membership
When I started contributing in 2017, we only had compiler team members - who did reviews, could merge patches, participated in triage meetings and voted on FCPs.
After a while, we realised that we wanted to be able to recognise contributors who had been contributing for a while, and who we wanted to grant additional permissions and responsibilities to - namely having merge rights and being on our review rotation. We also wanted a way to grow the team with contributors who didn’t need as much mentoring and could start leading bigger chunks of work independently.
At the time, the compiler team had a “meta” working group that was responsible for clarifying and drafting the compiler team’s policies - one of our first goals was to establish a role in the team for these contributors.
Originally, when we were discussing this idea at wg-meta meetings1, what would become the “compiler team contributor” was called “journeypeople”. We discussed ideas like having journeypeople be nominated and then mentored by existing team members - a sort of rite of initiation that would make sure that new team members knew how to use their newfound responsibilities.
Compiler team membership today
In the end, we landed RFC 2689 establishing the “compiler team contributor” role that we have today. Not a lot has changed since that was merged back in April 2019, we’ve still got two roles - compiler team contributor and compiler team member.
Compiler team members and contributors nominate new contributors, and members nominate new members. Everyone gets merge privileges, is added to the GitHub organisation, can use our various bots to trigger performance benchmarking and things like that. All of that works like the RFC describes.
However, there are some parts of RFC 2689 that I’m not sure we stuck with for very long - we forgot quite quickly that we intended working groups to always have a team member as a co-lead, for example, and not every contributor starts as a working group participant.
Re-visiting compiler team membership
Increasingly, there’s been a feeling that we’re hitting the limits of this team structure, that we’ve learned some lessons about what works and what doesn’t for us, and it’s time to try something new.
Within the Rust project, the compiler team is one of the largest teams and tends to have growing pains first, and our solutions sometimes act as a template for other teams when they hit the same pains - the library team created their own library team contributor role in 2019 and the rustdoc team this year.
There are four primary issues that I’d like to fix by changing how we do membership: we’re not very good at nominations; the contributor/member distinction is confused; team membership implies privileges; and the responsibilities of team members are becoming more diverse.
Compiler team membership has always involved existing members nominating other members. We’re not very good at this though: it’s easy for your contributions to go unnoticed if you aren’t working closely with a team member, or you are getting lots of different reviewers assigned (because you contribute to lots of different parts of the compiler, for example). We also tend to forget when a compiler team contributor isn’t already a compiler team member - if I had a penny for every time I’ve heard someone say “so-and-so isn’t a compiler team member already?”, I’d have a lot of pennies! None of that is particularly fair, and we don’t want our valued contributors (particularly those that we already think of and consider members) to be disenfranchised if they fall through the cracks and members haven’t remembered to nominate them for promotion.
One of the themes of my previous post was that we should design our team’s processes around things that we know we’re good at - we’re good at regular tasks, like performance triage, and less good at one-off administrative tasks, like nominating contributors - so we should try and make more one-off things into regular things.
Rust is also in a very different place today than it was when we created the contributor role - compiler team contributors and members have opportunities to get hired or sponsored to contribute. “Compiler team contributor” is a bit of a confusing title - if you aren’t familiar with the team’s structure, you might think that this is just someone who contributes to the compiler, rather than someone who is formally part of the project and has been recognised for their contributions. Nowadays that matters, and being able to say “I’m a compiler team member” instead of “I’m a compiler team contributor” on your CV can make a difference.
Team members and contributors have merge privileges, which is great, but we’ve found that we also want to be able to grant these rights to newer contributors that we trust so that they can work more effectively in their interest areas (such as Stable MIR or code coverage). There’s a tension here - granting these rights enables some contributors to work more effectively, which is good, but also makes becoming a compiler team contributor/member less of an achievement when you can be granted it quite quickly/easily.
As the team has grown, we’ve also started to have a lot more diversity in the responsibilities that team members take on. Some team members participate in our weekly triage meeting, making backport decisions and discussing nominated issues; other team members participate in weekly performance triage meetings, reviewing each and every pull request’s impact on compiler performance; other team members are on review rotation; and all team members need to sign-off on FCPs (final comment periods)2. It’s important that we recognise and highlight when team members participate in these important activities, but also, as team membership increases, not every team member will need to take part in all of these.
I’ve got some ideas for how we can change the team’s structure and membership process to address some of these issues, which may come as a Part II.
Thanks to Wesley Wiser for reviewing earlier drafts of this post.
If you’re interested in these original conversations, wg-meta’s 28/02/2019 and 14/03/2019 meetings and the original journeyperson RFC draft might be interesting.
FCPs are used by the team to sign-off on changes, things like stabilising a flag or feature.