On compiler team membership (part II)
How does one become a compiler team member?
Last time on Borrowed, I discussed some issues with our current team structure:
This time, some ideas for what we can change.
After discussions with team members and while reviewing the history of our team’s membership, I’ve had a few ideas for how we might change team membership to better serve the team today:
Separate privileges from membership
Eliminate the member and contributor distinction
Introduce additional opt-in “responsibilities”
Before describing these any further, a reminder: these are just some ideas - whether or not the team go forward with these ideas will depend on what team members think of them, and we’ll write up a proper RFC if we decide to make any changes.
Team members should be maintainers of the compiler - they should care about the health of the team and ensuring that the overall codebase is high-quality (even if they specialise in an area). Obviously, they’ll also care about their own individual projects and goals, as is the nature of open source contributions, but team members should be interested and willing to participate in activities that help the team achieve its goals.
Starting with that perspective, it might make sense to separate privileges from membership - having merge privileges and things like that are important for effective and efficient contribution, and so we should grant those to contributors that we trust, but that doesn’t necessarily need to imply team membership, which should be reserved for maintainers. It may make sense to scope merge privileges to specific parts of the compiler to non-members who are granted permissions.
Once an individual contributor can be granted privileges from the compiler team, we can collapse the distinction between compiler team contributors and members - this avoids the “compiler team contributor” role being a little bit confused and unintuitive, particularly for external parties.
How then do we choose compiler team members? I quite liked the way that we described our expectations around prospective members in RFC 2689:
But the general sense is that someone is ready when they have demonstrated three things:
"Staying power" -- the person should be contributing on a regular basis in some way. This might for example mean that they have completed a few projects.
"Independence and familiarity" -- they should be acting somewhat independently when taking on tasks, at least within the scope of the working group. They should plausibly be able to mentor others on simple PRs.
"Cordiality" -- contributors will be members of the organization and are held to a higher standard with respect to the Code of Conduct. They should not only obey the letter of the CoC but also its spirit.
I’d add another point, mirroring the perspective described above:
“Maintainership” -- they should be invested in the quality of the rustc codebase and the overall health of the compiler team, independent of any specific projects of theirs. They will participate in the tasks which keep the team functioning - reviews, triage, etc.
Our expectations of new team members is one half of growing the team, the other half is our processes for proposing new team members.
In addition to having expectations like those above - which are ultimately the standard that compiler team members must meet - we should also establish some more concrete criteria that contributors could meet to be considered for membership - things like having contributed for a specific amount of time, or having a certain number of merged pull requests. These criteria shouldn’t be binding or considered exhaustive, they’re just an indication that a contributor should be considered for membership. I hope that these criteria would help contributors feel able to ask to be considered for membership, because there are some clear thresholds they can see they have met, and automated notifications could be built around these criteria for team leads to notice contributors who should be considered for membership. Existing compiler team members could continue to nominate contributors who they feel meet the expectations of team members. Compiler team leads should also regularly ask team members if there are any nominations (perhaps every month or so).
As team membership would only be granted when a contributor has shown staying power in the project and contributes to the maintenance of the compiler, it would hopefully feel like more of an achievement and serve as a useful signal to potential employers or sponsors of these contributors that they’re an important contributor to the compiler team and overall Rust project.
Historically, growing the list of compiler team members has been avoided so that FCPs don’t take too long (waiting for everyone to sign-off can take a while!) - if we want to grow the team, then we need a way to scale our processes and recognise the additional responsibilities that some team members have.
We should establish a list of responsibilities that team members can get involved in1 - a responsibility is an involvement in one of the team’s important functions. We’re all involved in maintenance of the compiler, the team’s primary function, but there are a lot of secondary functions in the team that we need team members to organise and spearhead, but that not all team members would have an interest in, or that would benefit from having everyone involved:
FCP reviewer
It’s important that FCPs are properly considered, making sure that the change proposed doesn’t just look reasonable, but that all the details and alternatives have been considered.
When everyone on the team has to sign-off on FCPs then they take forever to complete, and team members who aren’t interested in every proposal just sign-off after a quick check for reasonableness.
Team members should be able to opt-in to the additional responsibility of FCP sign-offs, with the expectation that they need to take a detailed and thorough look at every FCP. We can always ask additional domain experts for their opinion on specific FCPs too.
Prioritisation and issue triage
One of the compiler team’s working groups make sure that regressions filed against the compiler are tagged with a priority - this work is vital to making sure that we don’t miss any critical issues which need addressed.
Backport approvals
Every week in the team’s triage meeting, team members review pull requests which have been nominated for backporting to the beta or stable branches, evaluating the risk/reward trade-off of each PR.
Not every team member is interested in these decisions and participates in this part of the triage meeting, so team members should be able to opt-in to the additional responsibility of reviewing backport nominations each week. Backport meetings could be scheduled according to the schedules of those interested in participating in backport nominations, and the team’s weekly meeting could focus on nominated issues and other parts of the agenda which are more widely considered valuable.
Performance triage
Every week, some of the team’s members triage each of the pull requests that had positive and negative impacts on compiler performance - ensuring that any regressions are addressed. This is very valuable work and it’s important that we recognise it.
Review rotation
At the moment, not every member of the team is automatically assigned to review new contributions. Our review rotation is going to be the subject of another of these posts in future, but for now, we should recognise those members who do get assigned reviews.
Any team member can start and stop their involvement in these responsibilities at any given time, and the team leads should try to ensure that each of the team’s primary and secondary functions are achieving their ends.
An important aspect of this would be recognising team members for taking on these additional responsibilities, which might look something like this on the Rust website:
Thanks to Wesley Wiser for reviewing earlier drafts of this post.
Correction: the compiler team’s prioritisation working group are focusing on prioritising regressions, not all compiler issues.
This is very similar to an old proposal from Niko that I stumbled upon while reading old conversations about team membership, suggesting we establish elected officers in the compiler team.