• Feature Name: not applicable
• Start Date: 2015-02-27
• RFC PR: rust-lang/rfcs#1068
• Rust Issue: N/A

Summary

This RFC proposes to expand, and make more explicit,

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

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,

• Sets
  セットする、集合
  the overall direction
  方向
  and vision for the project;
• Sets
  セットする、集合
  the priorities and release schedule;
• Makes final decisions on RFCs.

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

Most technical decisions are decided through the RFC process. RFCs are submitted for essentially all changes to the language,

The final decision to accept

What needs improvement

At a high level, we need to improve:

• Process scalability.
• Stakeholder involvement.
• Clarity/transparency.
• Moderation processes.

Below, each of these bullets is expanded into a more detailed analysis

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,

Part of the problem, of course, is due to the current push toward 1.0, which has both increased

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

A distinct

We need a way to scale

• Ensures each RFC is thoroughly reviewed by several people with interest and expertise in the area, but with different perspectives and concerns.

• Ensures each RFC continues moving through the pipeline at a reasonable pace.

• Ensures that accepted RFCs are well-aligned with the values, goals, and direction

  方向
  of the project, and with other RFCs (past, present,
  ある
  and future).

• Ensures that simple, uncontentious changes can be made quickly, without undue process burden.

Scalability: areas of focus

In addition,

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

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

We have taken some steps in this direction

Clarity and transparency

Despite many steps toward increasing

• The priorities and values set

  セットする、集合
  by the core team are not always clearly communicated today. This in turn can make the RFC process seem opaque, since RFCs move along at different speeds (or are even closed as postponed) according
  according to 〜に応じて
  to these priorities.

  At a large scale,

  規模を変更する
  there should be more systematic communication
  通信
  about high-level priorities. It should be clear whether a given
  与えられた
  RFC topic would be considered
  みなす、考慮する
  in the near term,
  項、用語
  long term,
  項、用語
  or never. Recent blog posts about the 1.0 release and stabilization have made a big step in this direction.
  方向
  After 1.0, as part of the regular
  普通の、正規の
  release process, we'll want to find some regular
  普通の、正規の
  cadence for setting
  セットする、集合
  and communicating priorities.

  At a smaller scale,

  規模を変更する
  it is still the case that RFCs fall through the cracks or have unclear statuses (see Scalability problems above). Clearer, public tracking of the RFC pipeline would be a significant improvement.

• The decision-making process can still be opaque: it's not always clear to an RFC author exactly

  正確に
  when and how a decision on the RFC will be made, and how best to work with the team for a favorable decision. We strive to make core team meetings as uninteresting as possible (that is, all interesting debate should happen in public online communication), but there is still room
  余地
  for being more explicit
  明示的な
  and public.

Community norms and the Code of Conduct

Rust's design

... 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

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

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

• Who is responsible for moderation?
• What about conflicts of interest? Are decision-makers also moderators?
• How are moderation decisions reached? When are they unilateral?
• When does moderation begin, and how quickly should it occur?
• Does moderation take
  とる
  into account past history?
• What venues does moderation apply
  適用する
  to?

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

To ensure

Subteams

The primary

• Shepherding RFCs for the subteam area. As always, that means (1) ensuring that stakeholders are aware of the RFC, (2) working to tease out various

  さまざまな
  design
  設計（する）
  tradeoffs and alternatives,
  代わりのもの、選択肢
  and (3) helping build consensus.

• Accepting or rejecting RFCs in the subteam area.

• Setting

  セットする、集合
  policy on what changes in the subteam area require RFCs, and reviewing direct PRs for changes that do not require an RFC.

• Delegating reviewer rights for the subteam area. The ability to r+ is not limited to team members, and in fact earning r+ rights is a good stepping stone toward team membership. Each team should set

  セットする、集合
  reviewing policy, manage reviewing rights, and ensure
  保証する
  that reviews take
  とる
  place in a timely manner. (Thanks to Nick Cameron for this suggestion.)

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

• Rust project leadership, in the form

  形式、形態、形作る
  of at least one core team member (the leader of the subteam).

• Area experts: people who have a lot of interest and expertise in the subteam area, but who may be far less engaged with other areas of the project.

• Stakeholders: people who are strongly affected by decisions in the subteam area, but who may not be experts in the design

  設計（する）
  or implementation
  実装
  of that area. It is crucial that some people heavily using Rust for applications/libraries have a seat at the table, to make sure we are actually addressing real-world needs.

Members should have demonstrated a good sense for design

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

• Setting

  セットする、集合
  up the subteam:

  • Deciding on the initial

    初期
    membership of the subteam (in consultation with the core team). Once the subteam is up and running.

  • Working with subteam members to determine

    決定する
    and publish subteam policies and mechanics, including the way that subteam members join or leave the team (which should be based
    基となる、基底(の)
    on subteam consensus).

• Communicating core team vision downward to the subteam.

• Alerting the core team to subteam RFCs that need global, cross-cutting attention, and to RFCs that have entered the "final comment period" (see below).

• Ensuring that RFCs and PRs are progressing at a reasonable rate, re-assigning shepherds/reviewers as needed.

• Making final decisions in cases of contentious RFCs that are unable to reach consensus otherwise

  さもなければ
  (should be rare).

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

• Technical discussion should take

  とる
  place as much as possible on public forums, ideally on RFC/PR threads and tagged discuss posts.

• Each subteam will have a dedicated discuss forum tag.

• Subteams should actively seek out discussion and input from stakeholders who are not members of the team.

• Subteams should have some kind of regular

  普通の、正規の
  meeting or other way of making decisions. The content of this meeting should be summarized with the rationale for each decision -- and, as explained below, decisions should generally be about weighting a set
  セットする、集合
  of already-known tradeoffs, not discussing or discovering new rationale.

• Subteams should regularly publish the status of RFCs, PRs, and other news related to their area. Ideally, this would be done in part via a dashboard like the Homu queue

  キュー

Core team

The core team serves

• Sets

  セットする、集合
  the overall direction
  方向
  and vision for the project. That means setting
  セットする、集合
  the core values that are used when making decisions about technical tradeoffs. It means steering the project toward specific
  特定の
  use cases where Rust can have a major impact. It means leading the discussion, and writing RFCs for, major initiatives in the project.

• Sets

  セットする、集合
  the priorities and release schedule. Design
  設計（する）
  bandwidth is limited, and it's dangerous to try to grow the language
  言語
  too quickly; the core team makes some difficult decisions about which areas to prioritize for new design,
  設計（する）
  based
  基となる、基底(の)
  on the core values and target use cases.

• Focuses on broad, cross-cutting concerns. The core team is specifically

  特に
  designed
  設計（する）
  to take
  とる
  a global view of the project, to make sure the pieces are fitting together in a coherent way.

• Spins up or shuts down subteams. Over time, we may want to expand the set

  セットする、集合
  of subteams, and it may make sense to have temporary
  一時的な
  "strike teams" that focus on a particular, limited task.

• Decides whether/when to ungate a feature. While the subteams make decisions on RFCs, the core team is responsible for pulling the trigger

  引き起こす
  that moves a feature from nightly to stable. This provides
  与える
  an extra check that features have adequately addressed cross-cutting concerns, that the implementation
  実装
  quality is high enough, and that language/library commitments are reasonable.

The core team should include both the subteam leaders, and, over time, a diverse set

Decision-making

Consensus

Rust has long used a form

... every design

設計（する）

or implementation

実装

choice carries a trade-off and numerous costs. There is seldom a right answer.

Breakthrough designs

Whenever possible, we seek to reach consensus through discussion and design

• Initial
  初期
  RFC proposed, with initial
  初期
  analysis
  解析
  of tradeoffs.
• Comments reveal additional
  追加の
  drawbacks, problems, or tradeoffs.
• RFC revised to address comments, often by improving the design.
  設計（する）
• Repeat above until "major objections" are fully
  完全に
  addressed, or it's clear that there is a fundamental choice to be made.

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:

• "Trivial" reasons, e.g., there is not widespread agreement about naming, but there is consensus about the substance.

• "Deep" reasons, e.g., the design

  設計（する）
  fundamentally improves one set
  セットする、集合
  of concerns at the expense of another, and people on both sides feel strongly about it.

In either case, an alternative

• For the "trivial" case, usually either the RFC shepherd or subteam leader will make an executive decision.

• For the "deep" case, the subteam leader is empowered to make a final decision, but should consult with the rest of the core team before doing so.

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,

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

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"

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;

Instead, the subteam decision is based

Keeping things lightweight

In addition

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

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

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.

Thus

Later, if an implementation

The teams

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

• Language
  言語
  design
  設計（する）
• Libraries
• Compiler
• Tooling and infrastructure
• Moderation

In the long run, we will likely also want teams for documentation

Language

言語

design

設計（する）

team

Focuses on the design

Some example RFCs that fall into this area:

• Associated types and multidispatch
• DST coercions
• Trait-based exception
  例外
  handling
• Rebalancing coherence
• Integer
  整数
  overflow (this has high overlap with the library subteam)
• Sound generic drop

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:

• Collections reform
• IO reform
• Debug improvements
• Simplifying std::hash
• Conventions for ownership variants

Compiler team

Focuses on compiler internals, including implementation

There is a more limited set

• Non-zeroing dynamic
  動的
  drops (this has high overlap with language
  言語
  design)
• Incremental compilation

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:

• rustdoc
• rustfmt
• Cargo
• crates.io
• CI infrastructure
• Debugging tools
• Profiling tools
• Editor/IDE integration
• Refactoring tools

It's not presently clear exactly

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

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

Moderation begins whenever a moderator becomes aware of a CoC problem, either through a complaint or by observing it directly.

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

• Except for extreme cases (see below), try first to address the problem with a light public comment on thread, aimed to de-escalate the situation. These comments should strive for as much empathy as possible. Moderators should emphasize that dissenting opinions are valued, and strive to ensure

  保証する
  that the technical points are heard even as they work to cool things down.

  When a discussion has just gotten a bit heated, the comment can just be a reminder to be respectful and that there is rarely a clear "right" answer. In cases that are more clearly over the line into personal attacks, it can directly

  直接
  call
  呼び出し
  out a problematic comment.

• If the problem persists on thread, or if a particular person repeatedly comes close to or steps over the line of a CoC violation, moderators then email the offender privately. The message should include relevant portions of the CoC together with the offending comments. Again, the goal is to de-escalate, and the email should be written in a dispassionate and empathetic way. However, the message should also make clear that continued violations may result

  結果、戻り値
  in a ban.

• If problems still persist, the moderators can ban the offender. Banning should occur

  起こる
  for progressively longer periods, for example starting at 1 day, then 1 week, then permanent. The moderation subteam will determine
  決定する
  the precise guidelines here.

In general,

Some situations call

The moderation team is responsible for interpreting

Moderators themselves are held to a very high standard of behavior,

Subteam, and especially core team members are also held to a high standard of behavior.

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

Drawbacks

One possibility is that decentralized decisions may lead to a lack of coherence in the overall design

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

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

Alternatives

代わりのもの、選択肢

There are numerous other forms

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

One seemingly minor, but actually important aspect is naming:

• The name "subteam" (from jQuery) felt like a better fit than "module" both to avoid

  避ける、回避する
  confusion (having two different kinds of modules associated with Mozilla seems problematic) and because it emphasizes the more unified nature of this setup.

• The term

  項、用語
  "leader" was chosen to reflect that there is a vision for each subteam (as part of the larger vision for Rust), which the leader is responsible for moving the subteam toward. Notably, this is how "module owner" is actually defined
  定義する
  in Mozilla's module system:

  A "module owner" is the person to whom leadership of a module's work has been delegated.

• The term

  項、用語
  "team member" is just following
  下記の、次に続く、追従する
  standard parlance. It could be replaced by something like "peer" (following the module system tradition), or some other term
  項、用語
  that is less bland than "member". Ideally, the term
  項、用語
  would highlight the significant stature of team membership: being part of the decision-making group for a substantial area of the Rust project.

Unresolved questions

Subteams

This RFC purposefully leaves several subteam-level questions open:

• What is the exact venue and cadence for subteam decision-making?
• Do subteams have dedicated IRC channels or other forums? (This RFC stipulates only dedicated discourse tags.)
• How large is each subteam?
• What are the policies for when RFCs are required, or when PRs may be reviewed directly?

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

Broader questions

There are many other questions that this RFC doesn't seek to address, and this is largely intentional. For one, it avoids