RFC 1068: Rust governance (sub-teams)

core (governance)

Summary

This RFC proposes to expand, and make more explicit, Rust's governance structure. It seeks to supplement today's core team with several subteams that are more narrowly focused on specific areas of interest.

Thanks to Nick Cameron, Manish Goregaokar, Yehuda Katz, Niko Matsakis and Dave Herman for many suggestions and discussions along the way.

Motivation

Rust's governance has evolved over time, perhaps most dramatically with the introduction of the RFC system -- which has itself been tweaked many times. RFCs have been a major boon for improving design quality and fostering deep, productive discussion. It's something we all take pride in.

That said, as Rust has matured, a few growing pains have emerged.

We'll start with a brief review of today's governance and process, then discuss what needs to be improved.

Background: today's governance structure

Rust is governed by a core team, which is ultimately responsible for all decision-making in the project. Specifically, the core team:

The core team currently has 8 members, including some people working full-time on Rust, some volunteers, and some production users.

Most technical decisions are decided through the RFC process. RFCs are submitted for essentially all changes to the language, most changes to the standard library, and a few other topics. RFCs are either closed immediately (if they are clearly not viable), or else assigned a shepherd who is responsible for keeping the discussion moving and ensuring all concerns are responded to.

The final decision to accept or reject an RFC is made by the core team. In many cases this decision follows after many rounds of consensus-building among all stakeholders for the RFC. In the end, though, most decisions are about weighting various tradeoffs, and the job of the core team is to make the final decision about such weightings in light of the overall direction of the language.

What needs improvement

At a high level, we need to improve:

Below, each of these bullets is expanded into a more detailed analysis of the problems. These are the problems this RFC is trying to solve. The "Detailed Design" section then gives the actual proposal.

Scalability: RFC process

In some ways, the RFC process is a victim of its own success: as the volume and depth of RFCs has increased, it's harder for the entire core team to stay educated and involved in every RFC. The shepherding process has helped make sure that RFCs don't fall through the cracks, but even there it's been hard for the relatively small number of shepherds to keep up (on top of the other work that they do).

Part of the problem, of course, is due to the current push toward 1.0, which has both increased RFC volume and takes up a great deal of attention from the core team. But after 1.0 is released, the community is likely to grow significantly, and feature requests will only increase.

Growing the core team over time has helped, but there's a practical limit to the number of people who are jointly making decisions and setting direction.

A distinct problem in the other direction has also emerged recently: we've slowly been requiring RFCs for increasingly minor changes. While it's important that user-facing changes and commitments be vetted, the process has started to feel heavyweight (especially for newcomers), so a recalibration may be in order.

We need a way to scale up the RFC process that:

Scalability: areas of focus

In addition, there are increasingly areas of important work that are only loosely connected with decisions in the core language or APIs: tooling, documentation, infrastructure, for example. These areas all need leadership, but it's not clear that they require the same degree of global coordination that more "core" areas do.

These areas are only going to increase in number and importance, so we should remove obstacles holding them back.

Stakeholder involvement

RFC shepherds are intended to reach out to "stakeholders" in an RFC, to solicit their feedback. But that is different from the stakeholders having a direct role in decision making.

To the extent practical, we should include a diverse range of perspectives in both design and decision-making, and especially include people who are most directly affected by decisions: users.

We have taken some steps in this direction by diversifying the core team itself, but (1) members of the core team by definition need to take a balanced, global view of things and (2) the core team should not grow too large. So some other way of including more stakeholders in decisions would be preferable.

Clarity and transparency

Despite many steps toward increasing the clarity and openness of Rust's processes, there is still room for improvement:

Community norms and the Code of Conduct

Rust's design process and community norms are closely intertwined. The RFC process is a joint exploration of design space and tradeoffs, and requires consensus-building. The process -- and the Rust community -- is at its best when all participants recognize that

... people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.

This and other important values and norms are recorded in the project code of conduct (CoC), which also includes language about harassment and marginalized groups.

Rust's community has long upheld a high standard of conduct, and has earned a reputation for doing so.

However, as the community grows, as people come and go, we must continually work to maintain this standard. Usually, it suffices to lead by example, or to gently explain the kind of mutual respect that Rust's community practices. Sometimes, though, that's not enough, and explicit moderation is needed.

One problem that has emerged with the CoC is the lack of clarity about the mechanics of moderation:

Answering these questions, and generally clarifying how the CoC is viewed and enforced, is an important step toward scaling up the Rust community.

Detailed design

The basic idea is to supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. Most of the RFC review process will take place within the relevant subteam, scaling up our ability to make decisions while involving a larger group of people in that process.

To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.

Subteams

The primary roles of each subteam are:

Subteams make it possible to involve a larger, more diverse group in the decision-making process. In particular, they should involve a mix of:

Members should have demonstrated a good sense for design and dealing with tradeoffs, an ability to work within a framework of consensus, and of course sufficient knowledge about or experience with the subteam area. Leaders should in addition have demonstrated exceptional communication, design, and people skills. They must be able to work with a diverse group of people and help lead it toward consensus and execution.

Each subteam is led by a member of the core team. The leader is responsible for:

The way that subteams communicate internally and externally is left to each subteam to decide, but:

Core team

The core team serves as leadership for the Rust project as a whole. In particular, it:

The core team should include both the subteam leaders, and, over time, a diverse set of other stakeholders that are both actively involved in the Rust community, and can speak to the needs of major Rust constituencies, to ensure that the project is addressing real-world needs.

Decision-making

Consensus

Rust has long used a form of consensus decision-making. In a nutshell the premise is that a successful outcome is not where one side of a debate has "won", but rather where concerns from all sides have been addressed in some way. This emphatically does not entail design by committee, nor compromised design. Rather, it's a recognition that

... every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.

Breakthrough designs sometimes end up changing the playing field by eliminating tradeoffs altogether, but more often difficult decisions have to be made. The key is to have a clear vision and set of values and priorities, which is the core team's responsibility to set and communicate, and the subteam's responsibility to act upon.

Whenever possible, we seek to reach consensus through discussion and design revision. Concretely, the steps are:

Consensus is reached when most people are left with only "minor" objections, i.e., while they might choose the tradeoffs slightly differently they do not feel a strong need to actively block the RFC from progressing.

One important question is: consensus among which people, exactly? Of course, the broader the consensus, the better. But at the very least, consensus within the members of the subteam should be the norm for most decisions. If the core team has done its job of communicating the values and priorities, it should be possible to fit the debate about the RFC into that framework and reach a fairly clear outcome.

Lack of consensus

In some cases, though, consensus cannot be reached. These cases tend to split into two very different camps:

In either case, an alternative form of decision-making is needed.

How and when RFC decisions are made, and the "final comment period"

Each RFC has a shepherd drawn from the relevant subteam. The shepherd is responsible for driving the consensus process -- working with both the RFC author and the broader community to dig out problems, alternatives, and improved design, always working to reach broader consensus.

At some point, the RFC comments will reach a kind of "steady state", where no new tradeoffs are being discovered, and either objections have been addressed, or it's clear that the design has fundamental downsides that need to be weighed.

At that point, the shepherd will announce that the RFC is in a "final comment period" (which lasts for one week). This is a kind of "last call" for strong objections to the RFC. The announcement of the final comment period for an RFC should be very visible; it should be included in the subteam's periodic communications.

Note that the final comment period is in part intended to help keep RFCs moving. Historically, RFCs sometimes stall out at a point where discussion has died down but a decision isn't needed urgently. In this proposed model, the RFC author could ask the shepherd to move to the final comment period (and hence toward a decision).

After the final comment period, the subteam can make a decision on the RFC. The role of the subteam at that point is not to reveal any new technical issues or arguments; if these come up during discussion, they should be added as comments to the RFC, and it should undergo another final comment period.

Instead, the subteam decision is based on weighing the already-revealed tradeoffs against the project's priorities and values (which the core team is responsible for setting, globally). In the end, these decisions are about how to weight tradeoffs. The decision should be communicated in these terms, pointing out the tradeoffs that were raised and explaining how they were weighted, and never introducing new arguments.

Keeping things lightweight

In addition to the "final comment period" proposed above, this RFC proposes some further adjustments to the RFC process to keep it lightweight.

A key observation is that, thanks to the stability system and nightly/stable distinction, it's easy to experiment with features without commitment.

Clarifying what needs an RFC

Over time, we've been drifting toward requiring an RFC for essentially any user-facing change, which sometimes means that very minor changes get stuck awaiting an RFC decision. While subteams + final comment period should help keep the pipeline flowing a bit better, it would also be good to allow "minor" changes to go through without an RFC, provided there is sufficient review in some other way. (And in the end, the core team ungates features, which ensures at least a final review.)

This RFC does not attempt to answer the question "What needs an RFC", because that question will vary for each subteam. However, this RFC stipulates that each subteam should set an explicit policy about:

  1. What requires an RFC for the subteam's area, and
  2. What the non-RFC review process is.

These guidelines should try to keep the process lightweight for minor changes.

Clarifying the "finality" of RFCs

While RFCs are very important, they do not represent the final state of a design. Often new issues or improvements arise during implementation, or after gaining some experience with a feature. The nightly/stable distinction exists in part to allow for such design iteration.

Thus RFCs do not need to be "perfect" before acceptance. If consensus is reached on major points, the minor details can be left to implementation and revision.

Later, if an implementation differs from the RFC in substantial ways, the subteam should be alerted, and may ask for an explicit amendment RFC. Otherwise, the changes should just be explained in the commit/PR.

The teams

With all of that out of the way, what subteams should we start with? This RFC proposes the following initial set:

In the long run, we will likely also want teams for documentation and for community events, but these can be spun up once there is a more clear need (and available resources).

Language design team

Focuses on the design of language-level features; not all team members need to have extensive implementation experience.

Some example RFCs that fall into this area:

Library team

Oversees both std and, ultimately, other crates in the rust-lang github organization. The focus up to this point has been the standard library, but we will want "official" libraries that aren't quite std territory but are still vital for Rust. (The precise plan here, as well as the long-term plan for std, is one of the first important areas of debate for the subteam.) Also includes API conventions.

Some example RFCs that fall into this area:

Compiler team

Focuses on compiler internals, including implementation of language features. This broad category includes work in codegen, factoring of compiler data structures, type inference, borrowck, and so on.

There is a more limited set of example RFCs for this subteam, in part because we haven't generally required RFCs for this kind of internals work, but here are two:

Tooling and infrastructure team

Even more broad is the "tooling" subteam, which at inception is planned to encompass every "official" (rust-lang managed) non-rustc tool:

It's not presently clear exactly what tools will end up under this umbrella, nor which should be prioritized.

Moderation team

Finally, the moderation team is responsible for dealing with CoC violations.

One key difference from the other subteams is that the moderation team does not have a leader. Its members are chosen directly by the core team, and should be community members who have demonstrated the highest standard of discourse and maturity. To limit conflicts of interest, the moderation subteam should not include any core team members. However, the subteam is free to consult with the core team as it deems appropriate.

The moderation team will have a public email address that can be used to raise complaints about CoC violations (forwards to all active moderators).

Initial plan for moderation

What follows is an initial proposal for the mechanics of moderation. The moderation subteam may choose to revise this proposal by drafting an RFC, which will be approved by the core team.

Moderation begins whenever a moderator becomes aware of a CoC problem, either through a complaint or by observing it directly. In general, the enforcement steps are as follows:

These steps are adapted from text written by Manish Goregaokar, who helped articulate them from experience as a Stack Exchange moderator.

In general, moderators can and should unilaterally take the first step, but steps beyond that (particularly banning) should be done via consensus with the other moderators. Permanent bans require core team approval.

Some situations call for more immediate, drastic measures: deeply inappropriate comments, harassment, or comments that make people feel unsafe. (See the code of conduct for some more details about this kind of comment). In these cases, an individual moderator is free to take immediate, unilateral steps including redacting or removing comments, or instituting a short-term ban until the subteam can convene to deal with the situation.

The moderation team is responsible for interpreting the CoC. Drastic measures like bans should only be used in cases of clear, repeated violations.

Moderators themselves are held to a very high standard of behavior, and should strive for professional and impersonal interactions when dealing with a CoC violation. They should always push to de-escalate. And they should recuse themselves from moderation in threads where they are actively participating in the technical debate or otherwise have a conflict of interest. Moderators who fail to keep up this standard, or who abuse the moderation process, may be removed by the core team.

Subteam, and especially core team members are also held to a high standard of behavior. Part of the reason to separate the moderation subteam is to ensure that CoC violations by Rust's leadership be addressed through the same independent body of moderators.

Moderation covers all rust-lang venues, which currently include github repos, IRC channels (#rust, #rust-internals, #rustc, #rust-libs), and the two discourse forums. (The subreddit already has its own moderation structure, and isn't directly associated with the rust-lang organization.)

Drawbacks

One possibility is that decentralized decisions may lead to a lack of coherence in the overall design of Rust. However, the existence of the core team -- and the fact that subteam leaders will thus remain in close communication on cross-cutting concerns in particular -- serves to greatly mitigate that risk.

As with any change to governance, there is risk that this RFC would harm processes that are working well. In particular, bringing on a large number of new people into official decision-making roles carries a risk of culture clash or problems with consensus-building.

By setting up this change as a relatively slow build-out from the current core team, some of this risk is mitigated: it's not a radical restructuring, but rather a refinement of the current process. In particular, today core team members routinely seek input directly from other community members who would be likely subteam members; in some ways, this RFC just makes that process more official.

For the moderation subteam, there is a significant shift toward strong enforcement of the CoC, and with that a risk of over-application: the goal is to make discourse safe and productive, not to introduce fear of violating the CoC. The moderation guidelines, careful selection of moderators, and ability to withdraw moderators mitigate this risk.

Alternatives

There are numerous other forms of open-source governance out there, far more than we can list or detail here. And in any case, this RFC is intended as an expansion of Rust's existing governance to address a few scaling problems, rather than a complete rethink.

Mozilla's module system, was a partial inspiration for this RFC. The proposal here can be seen as an evolution of the module system where the subteam leaders (module owners) are integrated into an explicit core team, providing for tighter intercommunication and a more unified sense of vision and purpose. Alternatively, the proposal is an evolution of the current core team structure to include subteams.

One seemingly minor, but actually important aspect is naming:

Unresolved questions

Subteams

This RFC purposefully leaves several subteam-level questions open:

These questions are left to be address by subteams after their formation, in part because good answers will likely require some iterations to discover.

Broader questions

There are many other questions that this RFC doesn't seek to address, and this is largely intentional. For one, it avoids trying to set out too much structure in advance, making it easier to iterate on the mechanics of subteams. In addition, there is a danger of too much policy and process, especially given that this RFC is aimed to improve the scalability of decision-making. It should be clear that this RFC is not the last word on governance, and over time we will probably want to grow more explicit policies in other areas -- but a lightweight, iterative approach seems the best way to get there.