Announcing the subteams!


I’m very happy to announce the initial makeup of the subteams, as per the governance RFC.

You can see the roster here:

These initial teams were selected by the core team (again, as per the RFC), but in the future the subteams themselves will maintain their own membership. We’ll be actually “starting up” these teams over the next few weeks.

Congrats, and thank you, to everyone who joined!

Below are some initial thoughts on how the subteams will actually operate.

Rust Subteams

The governance RFC leaves a lot of the operation of subteams intentionally unspecified. That gives us room to iterate, and for subteams to each evolve a setup that works well for them.

That said, we need a starting point, and this post lays out an initial framework for team operation.

How do subteams operate?

Venues for communication

The biggest question is: how do the subteam members communicate, both with each other, and with the broader community? The proposal involves a variety of venues, each suited best for different tasks, explained below.


Each team will have a dedicated, public, logged IRC channel. Altogether, the channels will be:

General channels

  • rust
  • rust-internals

Subteam channels

  • rust-libs
  • rust-lang
  • rustc
  • rust-tools

The #rust channel continues the role that it has today. The #rust-internals channel is intended for unfocused discussion targeting all Rust developers, while discussion among subteam members on the topics they oversee would take place on the associated channel.

We already have some of the subteam channels, but they have not seen much use. The hope here is that the change to formal subteams will give a stronger impetus to have focused discussion with the subteam in those channels.


Each subteam will have a dedicated category in which can be used for pre-RFC discussion, announcements, and raising questions and concerns in the subteam’s area. It is also where the weekly status report will be published (see below).

Discussion on active RFCs should take place as much as possible within the RFC comment thread itself (see below).

RFC comment threads

After a design reaches the stage of an RFC PR, further discussion should take place on that PR comment thread:

  • It centralizes discussion in one place, so that people do not have to track multiple forums to follow the discussion.

  • It keeps a simple, permanent log of the discussion connected with the RFC itself.

  • It allows commentary to point directly to text in the RFC.

The RFC shepherd should look out for cases of highly contentious discussion on the thread, however; this may indicate that the RFC should be closed in favor of a more free-form discussion in the discourse forum to help develop a consensus design (and fresh RFC).

Video/voice calls

Finally, the subteam may wish to organize ad hoc video/voice calls to discuss specific topics – most often, to work out new designs or priorities, but in some cases to discuss existing RFCs.

These meetings should not be a place for decision-making, but rather for high bandwidth consensus-building. This is a recognition that voice/video meetings are problematic:

  • They’re difficult to coordinate across time zones – Rust has developers everywhere!

  • They’re difficult for volunteers to commit to – asynchronous communication is much more flexible.

Thus, most of the work of the subteam should take place via asynchronous, textual communication, to allow the broadest participation. Meetings should be used to informally and quickly work through subteam issues. Some summary of the meeting (not necessarily a transcript) should be published in discourse afterward.

NOTE: the existing weekly Rust team meeting and triage meetings will be disbanded as part of this change. Triage is covered through subteams, as explained below. The Rust team meeting may be replaced by a regular “town hall” style open call in the future.

Levels of membership

Subteams will include several levels of participation, to balance inclusivity against the need for a constrained set of decision-makers. The levels are:

  • Leader. A member of the core team, as detailed in the governance RFC. The leader communicates to and from the core team, and helps sets team priorities and values; they also are responsible for ensuring regular progress on the subteam’s work.

  • Peer. A subteam member that is considered part of the official decision-making group. Decisions are normally made by peer consensus, with the leader taking charge in more contentious situations. Peers are expected to have an interest in and opinion on most of design coming through the subteam. They are not all required or expected to propose major new designs, however. RFCs are shepherded by peers.

    Of course, it’s understood that volunteers will sometimes have time to contribute and sometimes not, and so peers are not expected to be constantly, highly active, though they may lose peer status after long inactivity. Further, it’s understood that if a peer needs to step away for a period, RFCs may be accepted without their input; the process needs to continue working. (The “final comment period” will help at least as a last check if a peer has strenuous objections.)

  • Reviewer. Someone with r+ rights in the Rust repository for PRs in the subteam’s domain. All peers should be reviewers.

The set of peers is jointly responsible for adding/removing new reviewers, and peers.

Issue triage

As part of the anticipated 1.0 release, we recently instituted three priority tags in the github repo:

  • P-high. Should have a github assignee actively working on the issue. These are usually major bugs with high impact, or major features.

  • P-medium. Less urgent tasks that may still represent substantial effort. These are good choices for people wanting to dig deeper into Rust development, or for core contributors to tackle when in between higher priority items.

  • P-low. Almost equivalent to WONTFIX, except that the team would accept a patch closing the issue.

We continue to have the I-nominated tag for nominations, and the triage bot for recording them.

Each week, together with the weekly status report, the team leader will publish a report of the nominated issues to allow the peers to discuss prioritization and division of implementation work. Items that obtain P-high status are also announced in the weekly report (see below).

RFC/feature pipeline

For clarity, here is the full pipeline through which a major feature is expected to flow:

  • Pre-RFC discussion (IRC/discourse/meetings)
  • RFC PR
  • Shepherding
  • Final RFC comment period
  • Implementation
  • Final feature comment period
  • Ungating (decided by core team)

Peers have access rights to the RFC repo, and should assign themselves to RFCs that they wish to shepherd. If an RFC does not have a shepherd by the time it is announced in the weekly status report (see below), the leader should explicitly call for shepherds. The leader is also responsible for re-assigning RFCs whose shepherds have become inactive.

Sometimes an RFC is clearly not going to be accepted – usually because it is substantially lacking in detail, but sometimes because it is proposing a feature which has already been declined or is otherwise clearly in conflict with the current subteam priorities (which are set in conjunction with the core team, and should be clearly published on a regular basis). In such cases, a peer can suggest closing the RFC outright, but should check in with the leader before doing so.

The shepherd for an RFC is responsible for nominating that it move to final comment period. This step should usually be taken only after a basic consensus has emerged within the subteam peers. Nominations are provided directly to the leader, and if approved are announced in the following weekly status report (see below). Final comment periods are relevant both when moving toward merging, or toward closing, an RFC.

After an RFC is accepted, a tracking issue for its implementation is created. This tracking issue should be assigned to the person bearing most responsibility for its implementation. In cases where this isn’t clear, the team leader can put out a request for implementor in the next weekly status report.

Finally, after a feature has landed and baked in nightly releases for some time, a peer may nominate the feature for a final comment period. Similarly to the RFC final comment period, these nominations go to the team leader, and if approved are announced in the weekly status report. The comments go in a dedicated discourse thread.

At the end of a feature final comment period, the core team makes a final decision to ungate the feature.

Weekly status report

The subteam leader produces a weekly report for the team, which is posted to discourse. This report includes items like the following:

  • Major announcements
    • Major state transitions:
      • RFC opened
      • RFC entering final comment period
      • RFC acceptance (with planned implementor, or call for implementor)
      • Implementation landed
      • Implementation entering final comment period (for ungating)
    • Meeting took place, with link to writeup
    • Calling attention to significant discourse threads
    • Changes to team membership
  • Ongoing business
    • Dashboard of RFCs/feature pipeline
    • Coordination of implementation work
    • PRs that need reviewer attention

This report should make it easy to see the subteam’s major events at a glance. It should yield much greater visibility into the decision-making and implementation, helping to avoid surprising decisions or redundant implementation work. The “ongoing work” section should also help make sure that PR reviewing and RFC discussion do not get stalled.

The weekly cadence is, of course, adjustable; it may turn out to be too frequent.

Moderation team

The moderation team does not have a designated leader. It is responsible for interpreting the code of conduct into effective policy for IRC, rust-lang github repos, and the discourse forums.

In particular:

  • The set of IRC operators is determined by the moderation team, and will generally be a superset of the moderation team (to ensure coverage). The moderation team should set clear policies, including for situations like spamming, and can authorize changes to channel settings (such as a temporary move to voice only mode).

  • The team should employ discourse’s moderation tools, including flagging, and may wish to establish a set of deputies similar to the extended set of IRC operators.

  • The moderation team is directly responsible for github moderation as well. Here we have the least automated tools available; it is the moderation team’s responsibility to determine an effective way to moderate, via manual edits, bots, or requests to github.

The subteams are up and running!

It would be cool to have irc nicks on the teams page - I can’t be alone in not recognising many people by real name (although was designed to help with this).

I think it would be good to have the sub-team leader first for each team, I found pure alphabetical ordering a bit confusing


I opened as an proposal which puts IRC nicks there (on hover), thoughts?


As Jeanine Adkisson and others have pointed out on Twitter, the level of diversity on the teams is low: in particular there appear to be no women on any of the sub-teams. (Sorry if I am incorrect about anyone’s gender.)

As a member of the moderation team, I really really think this must change. There are many reasons, but for the moderation team in particular I don’t think we can be maximally effective at helping to uphold the Code of Conduct without a more diverse team. For example, gender bias and gendered harassment are a huge problem in online communities and open source. The moderation team is explictly supposed to fight sexism, racism, and other discrimination. We could see, anticipate, and respond to such issues much better if we had more than just male perspectives on the team.

I haven’t had a chance to talk about this with the rest of the moderation team yet, but speaking just for myself I am going to insist that we fix this issue. And I’d appreciate any help anyone in the community can offer.


First, before getting into the gender issue here, which is important, but focuses on a small part of the post: Thanks for the clarification. In particular, I was curious about the role of RFC shepard vs. subteam member, and this is clarified quite a bit now.

Thanks also for this note:

They’re difficult to coordinate across time zones – Rust has developers everywhere!

@nikomatsakis and I are not really that far apart, but between time zones and very different schedules, I’m asleep during most of the time that he’s working and online. I’ve never felt like I would be excluded from the project because of that, but it’s a minor inconvenience, and I know that some projects don’t consider this as carefully as they should when it comes to coordinating things.

On the topic of women on subteams, I very strongly agree with @mbrubeck’s comment. Even aside from the ethical considerations, there’s also the fact that having an all-male organization is self-perpetuating. As a bisexual and mixed-race guy, I’ve actually been reassured that Rust’s core team has made an effort to take the code of conduct and moderation seriously, be explicit about a non-discrimination policy, and in general that the community is pretty reasonable (in the places I frequent). So I don’t think that the Rust community is hostile to women (and I certainly hope not). But it looks very much like a boys’ club if everyone officially associated with the project is male, especially when that’s an even more skewed ratio than the tech industry has in general.

I know that if there are unusually few prominent women in the community, the core team and subteams can’t just invent people that they trust. But the gender skew is noticable, and an unfortunate attribute of a project that I’m otherwise proud to be a part of.

Diversity on the governance teams

I started a new thread about the diversity issue, to make the discussion easier to follow (I hope).


Can we get time zone information of Rust team members on the page? As one who lives in UTC+9, I have been frustrated by this issue for more than 10 years, but I have been too lazy to raise the issue actively. This seems to be a good chance.



Agreed. If we assume that I do indeed sleep, I live in IST (GMT+5:30). Generally in Mumbai. Available on weekends, usually.

But this probably should be displayed on the page too.


Is there any form of official communication medium for getting in touch with the mod team yet? I’ve noticed that while I can go to the subteam page, then find individual moderator’s IRC contact info and GitHub links, there doesn’t seem to be a central “contact the moderation team” anywhere.


We have set up as a temporary e-mail address to reach the entire moderation team. This is a private list; emails to it are visible only to members of the moderation team. (We’ll switch to an address at once the work has been done to set that up.)