Rusts current team structure is mainly ad-hoc and built towards independence. If there’s a group of people interested in the same thing, they get a label. That makes them addressable and shows that something is being worked on. Working groups are similar, but with a narrower scope. All of these are still rather ad-hoc, still. Usually, groups with a team-lead have formed.
What I believe has worked really well for the project up until now. It’s a process that’s easy to agree on and quick to implement. Also, there’s a fundamental agreement of trust between groups. Rust core has done a good job and fostering that.
I don’t think it’s going to carry us to the next level. It constrains us with regards to bandwidth and participation. A couple of ideas around that subject:
I think it’s time to move beyond single leaders. It’s odd that we build our teams towards independence, but the teams themselves are hierarchical. The community team is currently experimenting with floating roles and experiences look good. It has multiple advantages: it shifts away responsible from full-time Rust employees, while still being flexible enough to have hobbyists choose their own pace and effort. It also makes the team resilient against sudden changes. I’d like to specifically mention Ashley Williams for starting the change towards that model.
For most teams and WGs, the written down description and mission doesn’t go beyond their name. This may not sound like a huge problem, but it makes it hard to evaluate progress. While we’re doing public roadmapping on a project level, public roadmapping on a team level might make sense.
Also, not all teams are the same. While many of the technical teams have a clearly defined roles, some teams like community, mods and core have more flexible roles. They play different coordination roles. From the perspective of the community team, this job has become harder as the project grows.
From my point of view, this does for example stem from the fact that we haven’t clearly defined what we want to be kept informed about and what not or what other teams want to be informed about from us.
I think noting down these connections and expectations for all teams would be important.
The community team has set up (but, admittedly, underused it) a system of “associates”. Associates take no team member role and generally have no interest in joining meetings or following along. They register interest for certain subjects and will be queried when the subject arises.
This deal is to the benefit of both sides: community members are not feeling ignored on a subject they are good at, but the team also doesn’t need to carry the weight of keeping a full team member around that has no interest or no capacity to follow team business in full. This is a perfect position for hobbyists.
How does one join a team? What’s the base expectation? How to you propose a new team? How are working groups set up? All those questions are not clearly answered to our community currently.
This has been an ongoing problem since Rust 1.0, when the teams were announced out of the blue. That’s a ton of work we’ve been pushing off since then.
All in all, we need to work on reducing friction and increasing visibility.
top