Mini-post: the role of Rust's teams

The Rust project is run by its teams, such as the language team, library team, and community team. The teams are the primary structure for organising work and people in the Rust project, and effectively the only structure for governance. In this mini-post I want to enumerate what teams do and (briefly) how membership is decided.

Each team is different due to having a different scope of responsibilities - both the scale of those responsibilities and the domain - but I will generalise here. There are also working groups which are kind of mini-teams with more focus and less authority. The Foundation exists too, but is somewhat separate from the Rust project. Technically, the core team exists and has a different role and different parameters to the other teams. All these are out of scope for this post.

A team's role:

Decide on what should be done

By voting on RFCs, stabilisation FCPs, and other decision making, a team decides on what should be added to (or changed in) that team's domain. For example, the library API team decides on what APIs should be added to the standard library.

Decide on how things are done

By discussing designs, reviewing code, discussing bugs and their fixes, etc., a team decides on how things should be implemented and ensures that the design and implementation are of high quality. This is somewhat complicated by some domains having separate 'design' and 'implementation' teams. For example, for new language features, the language team decides on the design of the feature and the high-level implementation, but the compiler team is responsible for the actual implementation of the feature in the compiler. However, for both teams there are still multiple roles: the language team decides on whether a feature should be added to the language at all (above role) but also on the details of the design of the feature (this role). The compiler team decides on adding non-language features to the compiler, and the design and implementation of those features.

Project management

Teams triage bug reports, issues, and work items, communicate work, and plan larger pieces of work.

Set long-term strategy

Teams decide on where their domain is heading, produce a vision, and set priorities. This is most visible in the annual roadmaps which some teams do. But even where teams decide against an explicit roadmap, there is still an implicit strategy which informs how decisions are made.

Policy and process work

There are some policies and processes in the Rust project which are fairly global (the Code of Conduct, RFCs, the release schedule), but mostly teams decide on their own policies and processes, and how these are implemented.

Mentoring, growth, and people management

Via formal and informal mentoring, review, etc., teams mentor contributors and team members. Teams are responsible for ensuring they have team leaders and that those leaders have the required skills. Although there is no hiring and firing to be done, teams are responsible for their own membership, including recruiting new members, and encouraging contributors. They are responsible for managing communication within their domain and for resourcing planned work.

Be 'consultant experts'

Got a question about $X? Ask the $X team! As well as a team being the people most likely to be correct when answering a question, their answers are also the only ones which can be considered authoritative.

The default set of attendees for team meetings

This might seem inconsequential, but team meetings are where things happen and attendance is an important part of shaping decision making and staying informed. Teams set their own policies for meetings (if they happen, how they happen, who can attend), but the people on the team is the starting point for attendance, no matter the details.

Contribute to project leadership

In the past, teams have contributed to project leadership by their leaders making up the core team. Things are less straightforward now, but teams still contribute to leading the project as a whole.

Team membership

Teams are responsible for their own membership policies and for implementing those policies. Effectively, that means that teams choose their own membership. Different teams can choose different policies, but in reality all teams choose members based on some (implicit and explicit) combination of domain expertise, demonstration of impact, shared opinions/vision/outlook, and visibility to the team.