I’m very happy to announce the initial makeup of the subteams, as per the governance RFC.
You can see the roster here: http://www.rust-lang.org/team.html
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.
IRC
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.
Discourse
Each subteam will have a dedicated category in http://internals.rust-lang.org/ 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
- Major state transitions:
- 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.