Document how team leads rotate - #294
Conversation
We, the infra-team, committed to team lead rotations a few years ago, but never formalized the process to do so. Inspired by the compiler team's RFC on their rolling team leads, we have put together a document that describes the role of the team lead, how we use two co-leads with offset terms to ensure continuity, and the special role that the Rust Foundation plays for the infrastructure team.
Kobzol
left a comment
There was a problem hiding this comment.
I think that the t-infra/announcements post is unnecessary, as this is mostly an internal detail of the infra team.
Other than that, it looks great. Thank you very much for putting this together!
| immediately, and the length of the successor's term can be adjusted to | ||
| re-establish the staggering. |
There was a problem hiding this comment.
"re-establish the staggering" is hard to read as a non-native english speaker.
| This has a few implications for rotations: | ||
|
|
||
| - One of the two seats is effectively reserved for a Foundation employee. | ||
| With staggered two-year terms, the rotations alternate: one year, the |
There was a problem hiding this comment.
| With staggered two-year terms, the rotations alternate: one year, the | |
| In the two-year rotation: one year, the |
simplify
| - When a rotation would otherwise leave the team without a | ||
| Foundation-employed co-lead, only Foundation employees can be candidates | ||
| for the seat. |
There was a problem hiding this comment.
| - When a rotation would otherwise leave the team without a | |
| Foundation-employed co-lead, only Foundation employees can be candidates | |
| for the seat. |
isn't this obvious? 🤔
There was a problem hiding this comment.
It is, but since this is a policy I don't think it hurts to call it out explicitly.
| selection process applies, and the departing co-lead stays in the role | ||
| until their successor takes over. |
There was a problem hiding this comment.
| selection process applies, and the departing co-lead stays in the role | |
| until their successor takes over. | |
| selection process applies. |
Isn't this obvious? If not, what does this phrase add?
From my understanding the departing co-lead should give the leadership role asap, right?
| The rotation is completed by updating the [team database], the README of | ||
| this repository, and announcing the new co-lead in the | ||
| [t-infra/announcements] channel. |
There was a problem hiding this comment.
| The rotation is completed by updating the [team database], the README of | |
| this repository, and announcing the new co-lead in the | |
| [t-infra/announcements] channel. | |
| The rotation is completed by updating the [team database] and the README of | |
| this repository. |
As noted by Jakub, an announcement shouldn't be necessary.
|
looks great, thanks JD ❤️ |
|
Thanks for the feedback. 🙂 I dropped the announcement and rewrote some sections to be clearer. |
|
Mark in Zulip said agrees with the document. But he suggests to schedule the rotation in March, so that it doesn't overlap with Council and PD elections. Should we add this to the doc? |
|
Merging the policy according to what we agreed in #t-infra > meeting 2026-08-31 @ 💬 because no concerns were raised. I will suggest to schedule the rotation in March in a separate PR. EDIT: done in #299 |
We, the infra-team, committed to team lead rotations a few years ago, but never formalized the process to do so. Inspired by the compiler team's RFC on their rolling team leads, we have put together a document that describes the role of the team lead, how we use two co-leads with offset terms to ensure continuity, and the special role that the Rust Foundation plays for the infrastructure team.
Disclaimer: AI was used to iterate on the policy.