This document was originally distributed amongst the T-compiler members, and then to the compiler-contributors and to leadership elsewhere in the Rust project.
It is going to be effectively "open to the world" once Felix posts it to the Zulip stream for the Leadership and Succession steering meeting.
The aim for the document itself:
The aim for the steering meeting:
As usual, we will drive the meeting by inviting the readers to provide feedback, either by adding comments via hackmd's annotation system (highlight the text in a View pane and then add the comment), or by adding questions/discussion topics to the discussion topic queue at the bottom of the document (by adding the item itself in the Edit pane). Unfortunately the topic queue hyperlink seems to sometimes fight with hackmd's autoscrolling when the Edit pane is visible.
tl;dr: If being a compiler-lead is something you are interested in doing, you should read this document. If you care about what leadership of the compiler team means, you also should read this document.
Leadership of the Compiler Team, and selection of new leads, has been performed in an ad-hoc manner. This document tries to fix this by writing down 1. what the leads do today, 2. the minimum we expect from future leads, and 3. what process we should use for selecting new leads.
The motivation for writing this document: Felix believes a team like ours benefits from rotating leadership, both to prevent burnout for the leads themselves, and to encourage new leaders to step up and push the team towards new unexpected directions. But, to enable rotating leadership, we need to establish a shared vision for what our expectations are for our leaders, as well as the vision for what succession planning looks like.
If you, as a team member, want to give us feedback or talk about it 1:1, please let Felix/Wesley/both know by Thursday 2022-04-07, and we will schedule a follow-up meeting with you. If no one has any concerns, then Felix plans to propose a steering meeting on this topic at the 2022-04-08 planning meeting.
Let us, the compiler team, talk about how we manage ourselves today and our plans for how to do so in the future.
The compiler, as the development tool that is the literal embodiment of the language definition, is arguably the most important component of the Rust project. Of the teams that make up the Rust Project, the compiler team is easily the largest. T-compiler currently has 14 official members and an additional 23 "compiler contributors" who have many of the same privileges as full team members (such as r+ rights on the rust-lang/rust github repository).
Leadership of the compiler team matters: While a small co-located team can often operate without much structure, a large distributed team like T-compiler benefits from higher level coordination. Today, that coordination is mostly provided via 1. the T-compiler co-leads, and 2. the various subteams, working groups and project groups that members of our team contribute to, or lead outright.
This raises natural questions, such as:
This document is going to try to tackle those questions.
There are other questions you might have asked as well, such as:
This document is not going to try to answer those questions directly (though it might allude to them needing answers in the future). Some of those questions don't have one-size-fits-all answers. Others represent bigger issues that we do not want to try to tackle right now.
Wesley and Felix both see compiler team leadership as "servant leadership". We are not trying to push everyone to go do our thing. Instead, much of the role, as we see it, is just getting obstacles out of the way of the rest of the team. But (and this is an important "but"): Servant leadership is but one philosophy of leadership; Felix is not sure it is built into the role of T-compiler lead per se.
Felix's expectation is that the work performed by a T-compiler lead will naturally vary between different leads. Some leads will be heavily technical and want to focus their time on specific initiatives of interest to them, and will inspire their teammates to join them there. Other leads may invest the bulk of their time into project management as a whole. Still other leads may be most interested in building community and making the team itself more cohesive. Variation here is to be expected.
At the same time, it is important that the basic needs of the project are met. The compiler team leads are, in part, meant to be safeguards ensuring that each release of the Rust compiler meets a high bar for quality, while also continuing to progress forward in terms of the features it provides.
Let us first discuss the bare minimum that a team lead should provide.
Felix thinks the bare minimum can be described via two roles: 1. Team Representative, and 2. Decision Owner.
A team lead needs to be able to represent the compiler team, specifically when engaging with stakeholders.
A team lead needs to own decisions on behalf of the compiler team.
Today, Felix and Wesley try to manage covering the items above by:
In addition to the above, Felix and Wesley have each chosen at various times to:
However, we think it is important to note two things:
The common technical activities of a T-compiler lead are not glamorous: you need to be able to build the compiler and run its test suite. You should be able to bisect the git history. And you should be able to post pull requests, especially ones that revert existing changes.
To put it simply: We expect that any member of the T-compiler already has the technical competencies necessary to be a lead for the team.
One interesting aspect of the Rust compiler is that we actively encourage people to contribute to our code even if they have no background in compiler technology.
Similarly, Felix and Wesley do not believe someone needs to have expertise with every facet of the Rust compiler to be a compiler team lead. Simply put: It is too big a code base for anyone person to actually hold in their brain at any one time. (Of course we have proposals for things like "librarification" that might help with this, through the magic of "abstraction via specification"; but our code base does not fit that mold today, and we have no short-term plans for getting there.)
This is all a way of saying: We don't know about everything in the compiler, and we don't expect future leads to know everything either.
What a person who leads the team does need is enough social connection with the other T-compiler team members to feel comfortable reaching out for one-on-one communication when necessary.
Under our current model, the leads also need to be able to drive the Thursday and Friday team meetings.
For these reasons, we will use "membership in the T-compiler team" and "regularly attends the Thursday and Friday T-compiler meetings" as the main prerequisite to be a candidate for T-compiler leadership. (A record of leadership on one or more project groups or working groups is probably a good thing to have as well, but is not a strict requirement.)
Felix is not great at teasing apart how much time he has spent on the core items listed above. But, let us take a shot at it, since it seems important to set expectations for our leadership going forward. (Having said that, Wesley wants to stress that the real requirement is not a fixed amount of time each week, but rather flexbility in how you can spend your time.)
Issuing unilateral approval is done on a "as needed" basis. Likewise, engaging in asynchronous zulip conversations amongst leadership is done on an "as needed" basis. Let us assume one should set aside 2 hours a week for these activities, as well as addressing various "fires" that arise.
Driving the two weekly meetings takes at minimum 2 hours a week (for the meetings themselves). But there is some extra time to account for on top of that:
Wesley and Felix have a standing bi-weekly 30 minute sync-up meeting. They also communicate asynchronously on Zulip as needed. Let us say there's 1 hour a week on average for that.
Finally, authoring communications on behalf of the team has been done on both an as-needed basis (such as for the 1.52.1 blog post) and as part of a preplanned deliverable on the behalf of the team (such as for the 2022 ambitions post). Each such document represented a fairly significant amount of effort, though it was only required on an infrequent basis. Let us assume that activity like this requires 6 hours of effort once every six weeks; thus, 1 hour per week on average.
Overall then, we might say that T-compiler leadership should be expected to consume 8 hours per week, at minimum. That's in addition to whatever time you might spend on actual development work on Rust itself.
However, we emphasize again that this number is an average, and the variance is high: some weeks you might only spend an hour or two on T-compiler leadership duties. But then there will be rare weeks where you will spend 15 hours or more on these duties. In some ways, the most important attribute of a T-compiler lead today is flexibility with respect to how they can spend their time.
So far, T-compiler leadership has been a largely ad-hoc process. We have only had three eras:
Felix's memory is that their promotion to co-lead was a decision Niko made after recognizing that Felix's efforts in meeting management and issue triage effectively showed Felix was already acting as a co-lead, in terms of sharing team leadership responsibilities, since at least 2018.
Sometime in 2020, Niko decided they needed to step back from their T-compiler leadership duty in order to focus more effectively. Felix and Niko together felt shared leadership was healthier than relying on one sole leader at all times. Thus, they asked the team to nominate members whom the team thought would be good candidates to lead the team. Then, after reviewing the list of nominated members and speaking with each of the nominees, Felix and Niko selected Wesley to be the next T-compiler co-lead with Felix.
The main notable difference between these two events was that Felix organically stepped up to take on co-leadership duties without being named co-lead, while Wesley was selected by a slightly more formal process. (Of course, Wesley had already proven themselves as a capable leader based on their history leading a number of working groups, as discussed in the blog post announcing their new role.)
Niko served in their T-compiler leadership role for over five years. Felix plans to serve as co-lead through (at least) the remainder of 2022. Depending on how you count, that's a precedent of expecting a commitment of 4-5 years, at minimum, if someone signs up for T-compiler leadership.
However, we should not treat that precedent as established law. Four years is a long time.
Felix thinks it would be healthier to revise our expectations here: Team leadership terms should aim to cover two to four years, where that term covers both the time spent as a junior lead, and the time spent as a senior lead.
(If we can work through transitions in leadership successfully, then maybe we can push for even more frequent turnover in leadership. The stated two-year minimum was based on an expectation that we should allow for the junior co-lead at least one year to "learn the ropes" of leadership duties, and that implies an overall two-year cadence for team leadership duty. It is possible that a shorter period might suffice, especially as the team evolves.)
We think the co-leadership process we have used so far has worked pretty well. In particular: Having a pair of leaders, one "senior" and one "junior", where the last era's junior lead is the subsequent era's senior lead, works well in terms of transferring knowledge between eras. It also aids for calibrating leadership activity: A senior lead is meant to provide help the junior lead fine-tune their sense of how to prioritize issues that arise, and how to make decisions about things like beta backports.
One thing that is important when it comes to co-leadership is that the two leaders need to be able to work together effectively. We do not want to end up with a pair of leaders who cannot talk to each other.
Also, our expectations is that past leaders will remain available, at least for the short term. Niko is still a compiler team member, is active in the project, and has been available to consult when needed. We think that is a good model to follow: after each roll-over in leadership, the former senior leads should strive to be available for limited consultation when necessary.
Therefore, Felix proposes that going forward, we reuse the process that Niko and Felix adopted back in 2020: when the senior co-lead decides that they are ready to step down, and have confirmed that the junior co-lead feels ready to take on the senior co-lead role, then the two tell the T-compiler team privately about the intention to have a rollover in leadership.
Then the T-compiler team members can nominate their teammates to serve as the new junior co-lead. (In 2020, we allowed five days for nominations to roll in. Felix is inclined to deviate from that precedent, and follow the model of our FCP process: The leads should provide a ten-day window for nominations to come in, unless they get confirmation that the set of nominations is complete.)
After nomination is completed, the outgoing senior and junior co-leads discuss the set of nominees, and also, if desired, have short discussions with the nominnees. Then, the senior and junior co-leads select the new co-lead from the set of nominees. And that's it! Then they just need to publish a blog post saying that the leadership is rolling over, and say when it will happen.
One might wonder: If the two co-leads are going to select the new lead, why go through a nomination process? Shoudn't the co-leads just skip the nomination and select someone?
Here's why: it is important to give the team a chance to speak up in support of their candidates. It gives the leads a chance to see which other team members would be likely to get support during future rounds of succession planning. It also provides evidence that the nominee has a healthy relationship with the other members of the team, which we argued above is a defining attribute for a lead of this team.
This document isn't going to try to predict every bad thing that might happen. But there is one failure mode that is worth noting: What if a junior co-lead changes their mind, and decides they want to step down?
For now, Felix recommends that in this scenario, some previous senior co-lead steps into the vacant junior co-lead position (on a temporary basis) while a new junior co-lead is selected (presumably by reusing the previous set of co-lead nominees, or going through a new round of nominations if necessary).
This stepping into temporary co-lead position is just to allow proper sharing of workload, so that the current senior co-lead isn't suddenly facing twice the amount of work that they had before.
Right now, this version of the document is being shared privately between members of T-compiler.[2] Basically, Felix did not want to make any big statements about their plans or about how leadership is handled without first giving every member of the team a chance to weigh in with their own thoughts.
The next steps are: Felix and Wesley are both available to talk with any of you one-on-one. We want your feedback on this document!
If you, as a team member, want to give us feedback or talk about it 1:1, please let Felix/Wesley/both know by Thursday 2022-04-07, and we will schedule a follow-up meeting with you.
If no one has any concerns, then Felix plans to propose a steering meeting at the 2022-04-08 planning meeting to discuss this document (or the next iteration of it) with the broader T-compiler + compiler-contributor community. After that, there will probably be a T-compiler RFC to codify the ideas here as official policy for the team.
Thanks to you all for taking the time to read this, and for all the work you do on Rust itself.
Cheers,
Felix and Wesley
Add your question/discussion topic below, with its own ## header so that we can identify them easily.
pnkfelix: Is this what a question looks like? (Yes, it is!)
The social/conflict resolution aspect of the role may lessen in the future, depending on whether the project decides to take a more holistic approach to this problem, since it is a concern that cuts across many teams. ↩︎
Since the above was written, the document was subsequently shared with the compiler-contributors and with the other project leaders. And as of 2022-04-22, it is being shared with the world at large as part of the compiler team's open steering meetings. ↩︎
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe