add lang-team Major Change Proposals as a "pre-RFC" step

[nikomatsakis]

• Introduce a new step, a major change proposal (MCP), that is taken before an RFC is created.
  • Major change proposals are created by opening an issue on the lang-team repository. The issue includes a short summary of an idea with a focus on motivation and a de-emphasis on the details of the solution.
  • A Zulip topic is also created to discuss the proposal.
• MCPs can be resolve in a few ways:
  • If the proposal is small and approved, then a PR against rust-lang/rust can be created and FCP'd.
  • If the proposal is larger, and there is a willing lang-team liaison, then a project group can be chartered to draft an RFC.
  • Finally, the proposal may be closed, along with an explanation as to why. This may simply be that there is no available bandwidth to move the proposal forward right now.
• To help in tracking what the lang-team is up to, as well as the set of bandwidth available for each member, we will track (and make publicly visible)
  • Active project groups, grouped by liasion
  • Topics of interest that each member may wish to pursue
  • A design notes section that can be used to log exploration or discussions that yielded interesting results but didn't ultimately lead to a project group at this time.

Rendered view.
Flowchart of new process.

[tmandry]

I'm excited by this RFC. In my opinion, outlining a more complete process of how language design is done is really crucial to the evolution of Rust, and this RFC should help fix a number of problems with the existing RFC process.

Having worked through an MCP for the compiler team, there were some kinks still being worked out, but the overall outcome was greater clarity and more design-level issues being worked out early on.

[XAMPPRocky]

One thing that came to my mind while reading the RFC is what does the Major Change Process mean for lang PRs opened directly on rust-lang/rust? Should they be closed and redirected to rust/lang-team without prejudice? How major does a change need to be?

This is maybe self-evident by the fact that the idea is being proposed on internals or zulip rather than a PR, but I think it would be good to explicitly enumerate the kinds of changes that don't require the major change process, e.g. documentation.

[nrc]

I don't see any mention of what happens to RFCs without an MCP. i assume they are closed either automatically or manually, it would be nice to be explicit about it. Otherwise, the proposal looks great and I'm excited to see how it works in practice.

[nikomatsakis]

I don't see any mention of what happens to RFCs without an MCP. i assume they are closed either automatically or manually, it would be nice to be explicit about it. Otherwise, the proposal looks great and I'm excited to see how it works in practice.

Ah, you don't mean "pre-existing RFCs" (which I did try to address) but rather "new RFCs introduced after we adopt this system"?

If so, yes, I plan to close them and encourage the author to submit an MCP. I'll add a note about it, good catch.

[nikomatsakis]

@XAMPPRocky

One thing that came to my mind while reading the RFC is what does the Major Change Process mean for lang PRs opened directly on rust-lang/rust?

Yeah, this is a good question. We had a similar question arise in the compiler team. Our conclusion there was that we can encourage the author to submit an MCP but (typically) leave the PR open, simply in a blocked state. It's also ok to close, but it often feels more polite to leave it open.

The idea in the compiler team at least was that this encouraged folks to write some docs and the high-level plan and to communicate that out to the wider team, which is difficult to do from a PR This stems in part from the observation that the primary role of MCPs on the compiler team is probably encouraging planning, documentation and communication, more so than regulating changes, although they do also serve that function. On the lang team, I think that regulating changes ("do we want this") is going to be a bigger part.

Have to think a bit about it, but it seems like encouraging folks to write-up an MCP if the change is "real enough" makes sense.

(Separately but relatedly, I'm wondering about stabilization reports-- we currently have folks write them up, but it's not well documented, I don't think there's a template, and I don't think we collect them anywhere. It'd be nice if we did.)

[ratmice]

Just wanted to ask since projects like cargo also use the RFC process, whether the process here makes sense for it, e.g. I'm not particularly familiar with the lang-team's duties whether it is responsible for cargo RFCs. Or whether that would be better directed towards crates-io-cargo-teams?

Edit: Noticed there is a PR on that team proposing an RFC process,
cargo/crates io RFC process pr#35

Anyhow, I do think it'd be good to consider the other teams which currently piggy back on the existing RFC process, since primary impetus for this seems to be the existing RFC process hitting the limit of team throughput. It seems to me an argument can be made that it is contrary to that goal to piggy-back different teams into the same communications channels again.

[XAMPPRocky]

@ratmice The Major change process is definitely something the governance WG is considering recommending to more teams in general, but we agreed to first let the compiler and lang teams try it out the process and iterate on it first before recommending it to the rest of the org.

[PoignardAzur]

As someone with a RFC in the queue, so to speak, I'm obviously happy that the team is making the process more transparent.

That said, I'm not sure adding an additional step upstream will do anything except move the problem.

I expect with the new process, instead of RFCs accumulating in the PR queue without being assigned, we'll get MCPs accumulating in the lang-team issue queue, being reposted when they expire.

[Lokathor]

I also think that the root of the problem with the current RFC process is bandwidth issues rather than anything really to do with ideas regularly being too half-baked when first proposed.

There's literally just not enough spare time among lang team members to meet the demand.

That said I do think this proposal is a step in the right direction. I just think it's not the only step that's needed.

[ratmice]

@XAMPPRocky Cool, I guess my concern is that since cargo currently uses the same RFC process and RFC repository with the T-cargo tag, if lang moves to MCP as a "stage" for RFCs, but cargo/other teams do not, then there is potential confusion for contributors and different processes for triage of the rfcs repo.

When someone posts a new T-cargo labeled RFC shouldn't redirect them to the MCP process (unless the cargo process changes), but should for the lang-team appropriate RFCs.

Anyhow, I guess this comment is just elaboration of

Rationale and alternatives

• We could try this for all teams at once.
  • Why? Uniform process is good.
  • Why not? Not sure how it will work, and each team has somewhat different needs.

because in a sense the "Why not?" is really moving away from an existing uniform process.

[johansigfrids]

I have two comments:

If different teams will have different procedures this poses a challenge for external contributors. The areas of responsibility of the different teams is a bit of an insider baseball thing and you can't rely on external contributors knowing them. This means that somewhere early in your flowchart you need a step where the contributor somehow finds out under which team's area of responsibility their proposal falls so they know which procedure to follow.

My second comment is a bit more of a devil's advocate thing so don't take it too seriously.

I wonder if the RFC step carries its own weight anymore. When the RFC step arrives the proposal will already have lang-team buy-in, a project group and a polished design. So in the RFC step the proposal will have so much momentum, buy-in and investment that comments received during the RFC is highly unlikely to be able to make any meaningful change in practice and the proposal is already de facto done and ready for final review by the lang-team.

So why not get rid of the RFC step entirely? Instead have the project group present the design to the lang-team, and have the lang-team do comments or final yay or nay on it. Then, if it is accepted, have a publication of design document step that functions as the way to document designs and track what is being worked on.

[vi]

If omit the RFC step then what will be listed in "This Week in Rust" in section of ongoing decisions and commenting periods?

[nikomatsakis]

I wonder if the RFC step carries its own weight anymore.

I have wondered about the RFC processing carrying its own weight. I think it does still, but I could be wrong. I guess it will depend quite a bit on the RFC, but I still view the "RFC period" as the point where the idea gets exposure from the Rust community at large, and I think there's a good chance that this exposure turns up surprising cases that didn't come up when the group was first thinking about the problem or when the lang team was looking at it.

Of course those concerns may or may not prompt changes to the RFC, though at minimum I would expect the RFC to be extended with a summary of the concerns that arose from the RFC period and the thinking about them.

As an example of this, the inline assembly RFC was developing in a project group but I think it still underwent changes during its public RFC process.

[nikomatsakis]

I pushed some minor updates to the text.

[nikomatsakis]

I believe I addressed all the outstanding comments.

[nikomatsakis]

We are currently creating a few sample proposals on the lang-team repository -- I created one here in rust-lang/lang-team#23, although I suspect that it is rather longer than most proposals would be (or have to be, anyway). The Zulip stream creation automation is also hooked up, and you can see the resulting topics created in the t-lang/major changes stream.

[PoignardAzur]

We will look at pending proposals during our weekly triage meetings and try to post updates or questions promptly. Since the intent of a proposal is not to iterate on a design, but rather to determine if there is an available and interested lang team liaison, we should be able to move much more quickly in deciding whether to assign a proposal or not. The intent is to avoid the kind of limbo that we've seen in the past with pending RFCs.

Can you expand on that part?

In particular, "try to post updates" is a very broad goal to state. Everyone "tries" to do their paperwork on time, the problem is what happens when the process is strained.

What would you expect to be the standard duration between a proposal being submitted and the lang team response? How do you expect the process will adapt if that duration is consistently exceeded?

[comex]

Personally, I perceive this as making the process more opaque, mainly because it moves most discussion from GitHub to Zulip. Doing so has several downsides from the perspective of people not already intimately involved with the language team:

• Zulip streams, like any form of synchronous communication, don't make for good archives. People always complain about GitHub threads with hundreds of messages, but at least it's possible to read through them all. (Personally – yes, this is very subjective – I find this viable and, in fact, enjoyable.) With synchronous communication, the signal-to-noise ratio is much lower because people spend less time editing their messages; you really have to be there at the time.
• With synchronous communication, the difficulty of communicating with someone, or a group of people, is significantly affected by timezone differences.
• Zulip requires a login; you can't just link to a conversation and let everyone view it without registering an account.
• Zulip is less familiar than GitHub to most people.
• Zulip is not compatible with existing clients. With GitHub, you can read and participate in conversations from an email client, and this is my usual way of reading. For Zulip, I suppose the closest equivalent would be IRC, but there's no good Zulip-to-IRC gateway (and IRC is pretty flawed anyway). For this reason, I'm unlikely to be able to pay as much attention to Zulip conversations as I do to GitHub conversations.

I'm also a little torn about the goal of throttling proposals based on available implementor bandwidth.

Sure, the current situation is often counterproductive, with RFCs gathering large amounts of discussion only to be left open, closed as postponed, or even accepted but never implemented, all due to lack of bandwidth. Throttling proposals will help set expectations and prevent people from wasting time designing things that won't be implemented.

On the other hand… at least it provides an outlet to spread awareness of ideas that might make Rust better, even if they won't be adopted in the short term. Personally, I feel like I've learned a lot from RFCs that haven't been adopted. Admittedly, the new process still leaves room for open-ended discussion in internals threads (plus rust-lang/rfcs issues that nobody looks at). But I suspect there will be less of it.

[PoignardAzur]

With synchronous communication, the signal-to-noise ratio is much lower because people spend less time editing their messages; you really have to be there at the time.

Additionally, I've observed that with synchronous communication, people have a stronger tendency to refer to recent events without explicit links, which communicates information everyone understands at the time of the discussion, but becomes completely opaque when reading from archives.

[burdges]

There are good reasons for organizations to maintain internal synchronous communication channels, which includes shared assumptions, reduced editing, etc. Yet, these platforms' advantages make them suck as an archive like @comex says, while github does the archive and cross referencing business extremely well.

We use Riot/Matrix for this where I work because Zulip's walled garden terrifies us, btw. We do have public room but these exist to build community, provide outreach, and provide really low level technical support for sys admins, none of which appear relevant for rust. We kinda only invite developers we pay into research and development rooms.

I suspect doing this would only invite more noise into the "space where you think", including making your internal workload tracking noisy. You might instead consider heavier handed measures to reduce the github noise and move chatter to internals.rust-lang.org.

[nikomatsakis]

Yeah, I admit I share some of these concerns. The question of whether to use Zulip or not is one part of the proposal I've been rethinking.

I also definitely see the advantages of design proceeding "in parallel" -- I don't necessarily like how it's taking place on the RFC repository, but there might be a setup that "integrates better" with today's RFCs while achieving many of the same goals I'm reaching for here.

My concerns with Zulip are

• barrier to entry
• noise in the space where we think, as you say
• conversation more spread out (note though that the https://zulip-archive.rust-lang.org/ does make conversations there relatively easy to link to and so forth)

[nikomatsakis]

One thing I really like about MCPs today is their super lightweight nature -- i.e., I think we envision that if you have an idea, you can open an issue and sketch out the contents of the MCP inline, or at least compose one with relative ease in a hackmd and paste it in. It often doesn't take much to convey the "high-level idea", and the hope is that we intercept and decide on designs and directions in relatively early stages this way. But I think that it is not really suitable for heavy drafting and revision (not that github PRs actually are very good at that, either).

Anyway, I'm going to think about it.

[burdges]

Anyways, it's good if the RFC approval process stays (a) slow enough that enough review accumulates, and (b) open and engaging enough to attract enough good review.

[comex]

Yeah, I admit I share some of these concerns.

I also definitely see the advantages of design proceeding "in parallel" -- I don't necessarily like how it's taking place on the RFC repository, but there might be a setup that "integrates better" with today's RFCs while achieving many of the same goals I'm reaching for here.

Thanks for taking my thoughts into consideration :)

FWIW, I actually agree with most of those goals.

• conversation more spread out (note though that the https://zulip-archive.rust-lang.org/ does make conversations there relatively easy to link to and so forth)

Also, I hadn't heard of this archive before. That does help with the "can't view linked discussions without logging in" issue, though only if people actually use it. Perhaps an archive link could be added to the "This issue is not meant to be used for technical discussion. There is a Zulip stream for that." boilerplate? Having two links (one for participating, one for viewing without logging in) might be a bit confusing, but running into a login screen is also confusing (e.g. the first time I saw it, I wasn't sure whether or not it was open to the public), so I think adding it would be an improvement overall.

[nikomatsakis]

I'm going to withdraw this RFC and open a revised one. We've been trying out this policy for a while and @joshtriplett and I had some plans to do a revised version of this process, one that covered more of the lifecycle of a feature.