One of the big priorities for the Rust Leadership Council has been to determine the "shape of Rust." For a long time I've wanted to write a comprehensive blog post about what I think the shape of Rust should look like. Unfortunately, I've had too many competing priorities to write something fully comprehensive. This post is not that post, but I did want to try to put down a couple ideas I've been thinking about recently.

I want to touch on three things. These aren't necessarily in priority order or anything, but they are all things that I think would be useful for various reasons. The three things in this post are:

1. Create structures for support roles
2. Create a Design Team
3. Separate Project Membership from Team Membership

Create structures for support roles🔗

While I've listed this as one major idea, I think there are at least two ideas that could fit under this heading:

• Create a Council Staff Team
• Provide Project-wide support

But first, let's talk about support. This area has been a bit of a revelation for me. When talking about how to spend Rust's budget, people regularly mention hiring support staff. I haven't been sure what we'd do with this staff, but I was curious because a lot of people I trust seemed to think it was a good idea. Throughout my career, I often haven't had an amazing experience with roles like project managers, program managers, technical program managers, etc. I imagine a lot of this was me not understanding the value they brought so it felt like they were just asking me to fill out TPS reports and show up at meetings to talk about all the things we haven't done since the last meeting because we were in meetings. To the excellent people in this roles I've worked with before, I apologize for undervaluing you!

When people in the Rust project talk about support, there seem to be envisioning a few different things, such as:

• Project/program management: Keep track of project status, open issues, make sure people are working on them, etc.
• Engineering support: This role would work on things like triagebot and other software tools to help the Rust project work more efficiently. One thing I'd personally love here is a way to set personal limits on my review queue, like "I'm willing to review two PRs per week."
• Secretary or Executive Assistant: Keep minutes for meetings, coordinate scheduling as needed, keep track of upcoming or recurring deadlines, etc.

While my intention here is to express that these things are valuable, I'm sure I'm selling each of these roles short. Unfortunately, this is often the kind of work that is more visible when it goes poorly than when it goes well. I'm sure I'm missing a lot of things that support staff provide because they do it so well no one notices.

Anyway, let's dive into these two approaches to support roles.

Create a Council Staff Team🔗

RFC 3392, which created the Rust Leadership Council says repeatedly that the Council should mostly delegate rather than do the work themselves. In my opinion, this is something that we on the Council have not done an amazing job of. I also commonly hear people not on the Council say "I wish you would delegate more."

A big part of the reason why this is the case is that each time we delegate we have to decide who to delegate to. Many times this means creating a team, or subcommittee as we've tended to call small project groups doing work on behalf of the Council. It turns out, creating a subcommittee is a lot of work. So we're often faced with a choice between doing a lot of work to find volunteers for a new subcommittee and then waiting for them to do the work, or just doing the work ourselves. Because so far our subcommittees have been focused on a single project, we don't really get to reuse the work of building the subcommittee. I could imagine if the same subcommittee did several projects, then the tradeoff looks a lot more attractive because we can amortize that effort over future projects.

The idea of the Council Staff Team is basically to amortize the effort of creating subcommittees. We would find a set of people to initially fill the team and part of their charter would be to continue to find people to maintain and grow the team as needed. The Council Staff then becomes the default place for the Council to delegate to when there is no obviously better place already existing.

The analogy I've had in mind most while thinking about this is a congressperson's staff. At least in the United States (and I assume in many other countries), although the legislature officially has the power of writing and voting on the laws, the actual elected members do not write the thousands of pages of legislation they vote on (as far as I can tell they don't even read them). Instead, at least in theory, they tell their staff what priorities and goals are important to their constituents (or maybe their donors instead) and ask their staff to do research and design policies that they believe will achieve these goals.

I imagine the Council Staff Team could work similarly. As the Council, we would identify priorities and things that need to be solved for the project. These things are likely to be hard and things that we as representatives of the various Rust times likely lack the necessary background to solve well. On the other hand, the Council Staff team would ideally be filled with people who love researching and designing policies! So they would work with the Council to draft policies to meet the goals decided by the Council. These would then be presented back to the Council, and perhaps made into project-wide RFCs if needed, and we could decide to adopt the policy.

Provide Project-wide support🔗

I'm a bit less clear on this section, but several people have raised ideas in this space and I think it warrants some exploration.

Several people have cropped up across the Project who have taken on either support or project management roles. These people do things like curate the agenda for team meetings, facilitate meetings, keep track of what issues need triaged, what RFCs and decisions are in progress, and often do a lot of work unblocking progress on these things. Everyone who works on teams with one of these volunteers has given absolutely glowing feedback on how having someone to do this work has kept things in the project moving smoothly and have accelerate the progress. Seeing these success stories in various points across the Project is a major part of why I'm really excited about the value that support work provides!

I think every team should have someone who's keeping things moving smoothly like this.

The question is how.

It's tempting to make a new team, like T-operations or T-support. The people who have been doing this work already would become founding members of this team and hopefully the team would grow over time. We could even hire people for this role. Then team members would sort of roam around to other teams and provide their services.

I think there are some ways this approach may not work as well. It reminds me somewhat of corporate structures, where you typically have a dev organization and a PM organization. The PMs are assigned to a certain dev team, but because their have their own separate reporting chain, this can lead to the PMs' goals and the devs' not being aligned.

It's easy to focus on the org chart and say things like "Oh, we want more people doing project support work, so let's make a team." This may be the right answer, but I think there are some more fundamental goals that should drive this decision.

First, these support people need to be deeply embedded in the team they support. Some of the work looks somewhat standalone at first. For example, building a triage agenda can be done by pulling a couple GitHub labels and putting them in a HackMD. Indeed, we have several bots that do this. However, this work often requires much more context to be maintained, and this context is not always visible. This is especially true when it comes to decisions where there are competing proposals. One of the things the people doing support work that I've worked with in the Rust project do is compile lists of various positions and the major concerns and values driving those positions. They actively seek ways to find common ground and unblock things. In my experience, they know the nuances of the issues they are bringing for discussion better than anyone else. Doing this work requires close ties to the team.

Second, we need to make sure we have ways to sustain and grow this work. This is hard, unrelenting work, and I suspect prone to burnout. We want to make sure people doing support work are themselves supported and appreciated. Where it makes sense, this should include financial support. There are needs for more of this kind of work across the project, so we need to inspire more people to contribute in this way. This is one area where a centralized operations team could help, since the team would be able to mentor contributors doing this work. I think as a matter of project culture, we should make an effort to highlight this work that's being done (because it's easy to overlook), to celebrate it, and to appreciate those who do it.

Create a Design Team🔗

Another thing I'd like to see is the creation of T-design. The goal here is to encourage a unified design of Rust as a product.

I think the development process of Rust has really shone when it has been able to do codesign between the language and the standard library.

One early instance of this is when the Vec type became just a regular type in the standard library. Earlier, Vec was a primitive type built into the compiler. When you did an push operation, for example, the compiler would plop down some LLVM code right there to do the operation. As the language got more powerful, we realized we could move Vec to the standard library. This made Vec easier to implement and maintain, since it was just regular Rust code; safer, because it was written in Rust and automatically got all the safety guarantees Rust gives you; and faster, because... well, I'm not sure why we couldn't have done the same optimizations in LLVM but I recall the library version was faster.¹

Another instance is the addition of the ? operator. The Result type had been well-built in the standard library, but using it was still a little clunky. Adding the ? operator to the language worked hand-in-hand with Result that was already in the library to make for a much nicer experience.

I want to make sure Rust is able to always do this kind of codesign, and pulling the teams that own the design of Rust under one umbrella seems like an obvious way to do this. To start with, I'd bring T-lang and T-libs-api under the T-design umbrella. These are the design-oriented teams I happen to be most familiar with, but others have suggested to me that tools like Cargo have design needs that could also fit here.

Of course, this raises the question of how to operationalize this change.

One option is to merge T-lang and T-libs-api into one team, so we no longer talk about either team separately but only talk about T-design. I don't think this would be ideal. The teams exist now because they have different goals, needs, work, etc. They also have well-established ways of working that I wouldn't want to disrupt too much. The goal is to improve what's already good, not start over.

Instead, I imagine T-design being a very small container team that continues to delegate almost all of its purview to T-lang and T-libs-api.

But then, who is would be a member of T-design, and what powers would they retain? I would start with a small number of people drawn from T-lang and T-libs-api who have deep experience with the design of Rust and a long tenure in the project. They wouldn't be involved with the day-to-day design work; if they want to do that they would also be members of the subteams. But they would be responsible for making sure the Rust, both the language and standard library, feel like a unified whole and that all the parts support each other. In concrete terms, I imagine this happens through being able to raise blocking objections for either team if something violates the overall unity of Rust's design, and also through owning decisions in cases where the language and library elements of the design are particularly inseparable.

What about T-impl?🔗

When I first started floating this idea, I phrased it as building two top level teams: T-design and T-impl. T-design would be, as described in the previous section, made up of T-lang and T-libs-api, and would own the overall design of the language and libraries. T-lang would consist primarily of T-compiler and T-libs, and they would implement the design that is created by T-design.

There's a nice symmetry to this, but at this point, I think the motivation for T-impl is not as strong.

There's a lot of similarity in that, oversimplifying a lot, they both write lots of code. But from what I can see, this code does not really need to be developed together. Once the compiler implements new language features, the standard library can start to use them. If those features enable new library features, then the compiler can use those.

I guess one case where a T-impl team would make sense is if there were cross cutting concerns that needed to be managed in a centralized way. In corporate environments, for example, security concerns often have this shape.

Still, at this point in time I see less benefit to reorganizing the implementation-focused teams, while I do see benefits to bringing the design-focused teams closer together.

Separate Project Membership from Team Membership🔗

This last section is the one I'm by far the least confident in, but I want to suggest the idea anyway, discuss the goals underlying it, and other options that might work instead. I think I first heard this idea floated at the recent Rust Leads Summit.

Right now, Project membership is essentially the union of all the various Rust teams. I would suggest refactoring these a bit. Under this proposal, we'd have a set of people called the Rust Project Members. Team members would then be pulled from that set.

The first order goal here is to make it easy to recognize people who contribute heavily to the Rust project in various ways, often across teams, but may not have yet been invited to a maintainership role on a Team. I'm unclear on what would be the exact requirements or procedures for becoming a member, but it's roughly someone who is recognized by other members (perhaps Team members) as someone who contributes recognizably and significantly to the project.

Underlying this goal are a couple others.

One, the Foundation often needs to know who the Project Members are. Part of their mission is to support the set of maintainers governing and developing the project. In order to do this, they need to know who those people are. So far we've been using anyone on the all@rust-lang.org mailing list as our working definition, but this is not an ideal set. In particular, this mailing list does not include everyone who is developing the project and should be eligible for Foundation support. If we created a clear group of Rust Project Members, which includes all the maintainers (roughly Team Members now) and also others making significant contributions, then we have a much better set to give the Foundation when needed.

Part of why this matters is that the Foundation is looking at more ways to support Project Members. While nothing is set in stone yet, this could include things like helping to buy a headset for someone who has a less than ideal audio situation but wants to participate in team calls, or helping to cover travel costs for Project Members to attend conferences.

And this leads into my second motivation, which is to remove friction from supporting the Project. The Foundation has a lot of resources that it can use to support the project. One of my biggest concerns is that we'll spend too much time talking about how to best support the Project and then not spend any of the money or use any of the other resources we have. I'd rather make it easy to use the resources. We may not always use them in the very best way possible, but we can learn from these mistakes and be more effective going forward.

To this end, if we have some kind of support available to the Project, like hardware or travel support, I'd like to make the decision as much of a rubber stamp as possible. If a request comes in, I want to say "this support is available to Project Members? Are you a Project Member? Yes? Okay, here you go." The alternative is that we need to have some more in depth application and review process. This discourages people from applying in the first place, and adds some ambiguity to the application review process.

Of course, there are challenges. Having low friction like this means it's imperative that the Project is a high trust organization.

If we had a general set of Project Members, we need to make sure the process for including people in it are fair. We also need a regular review period to make sure the roster stays up to date. It can be awkward if someone needs to be removed. In effect, all the challenges I mentioned with reviewing applications have to instead be resolved at the point where someone wants to become a member of the Project.

And there are other ways to accomplish these goals as well. For example, more teams are adding T--contributors teams. In effect, what I'm proposing as the Project Members group would be the union of all the T--contributors teams.

And this proposal may not address the other real problems. For example, contributors do not always want to ask for membership, and teams can sometimes overlook adding someone who has been significantly contributing for some time. It might be better to directly address the questions and processes for team membership rather than creating a new organizational structure and doing it as part of that process.

Conclusion🔗

One of the tasks the Leadership Council was encouraged to do, and has decided to do, is to consider the boundaries and organization of the Rust Project. This is obviously a huge project.

In this post, I've shared some ideas in this space that I think are worthy of consideration. I'm sharing them here in part so that others can consider them, but also to spark discussion, brainstorming, and alternate proposals.

These have some pros that I hope I've laid out, but there are also open questions that I've also touched on. I'd love to hear other folks' ideas on how to effectively organize the Rust Project!

---