Pre-meta-RFC: rate limiting the firehose

[Centril]

@mark-i-m

As soon as an RFC PR is posted on the repo, rfcbot comments with a Table of Comments (ToC) (<-- heheh get it?) comment. The ToC is empty at the beginning and will be built up as the discussion continues.

A PR is welcome to rfcbot; this doesn't require an RFC, just implementation work. Relevant issue:

Please automatically post the `Rendered` link

@mark-i-m

• rfcbot then asks the poster to identify a team to assign the RFC to.

What's the point to this delay? I do RFC triage usually within minutes of an RFC being filed. Furthermore, a poster might not know what team to assign and there may be multiple teams to assign.

@mark-i-m

The rfcbot then assigns the RFC to a member from the team to be the RFC’s shepherd.

In T-lang, we do RFC assignment more deliberately than this; in meetings where we have extra time after triage (issue/PR triage almost always comes first...) we assign members based on area of expertise and interest; I like to believe this has a better outcome than random assignment. The fact that we are limited by triage and team meeting time acts as a natural rate limiter on accepting proposals. For example, during the work on the edition we were doing a lot of triage and most accepted language design was driven by edition necessities.

@mark-i-m

A member of the Rust team (or the OP?) may issue a note command to rfcbot on that thread to add a summary of discussion to the ToC. I propose that this should be limited to 250 characters, plus links to appropriate comments and related other links.

Doesn't require an RFC; just implementation. I'd accept such a PR; I'm generally in favor of giving team members more commands in their toolbox to use at their volition.

@mark-i-m

At most C comments can occur between note s. If C comments occur and nobody has issued a summary note of activity since the last note , rfcbot locks the thread . I propose C = 30 because that’s about the most I can keep up with before I give up on following a thread.

Note sure I can accept this without T-core approval however. I would note that not all comments have the same density; for example, line comments that fix typos that get resolved quickly you don't need to keep up with.

@mark-i-m

Individuals and interest groups are encouraged to discuss proposals on their own repos or on internals before posting the RFCs repo.

This already happens?

@mark-i-m

RFC discussions can get quite lengthy, which is exhausting to read and participate in, both mentally and emotionally. Even highly dedicated individuals, such as Rust team members, have expressed this feeling.

I think this is more about the RFC than the discussion format. I think any proposal about error handling will for example be quite long. Meanwhile, an RFC like RFC: Associated type defaults by Centril · Pull Request #2532 · rust-lang/rfcs · GitHub gives the opposite feeling.

@mark-i-m

GitHub collapses comments in the middle

This is quite annoying yes; maybe we could solve it by reaching out to GitHub and ask for a setting?

@mark-i-m

Many RFCs get accepted without the necessary bandwidth to push them to completion. This leads to many people using Nightly rust because that’s where their favorite feature lives in pseudo-limbo for the foreseeable future.

This is not my experience; RFCs either a) get implemented quickly, b) are blocked on design questions, c) are blocked on larger architectural movements (e.g. chalk). Do you have concrete evidence for this claim?

@mark-i-m

Many proposed features don’t fit clearly into the roadmap.

I think that's fine -- and welcome even; these are usually small proposals that someone who's interested can implement on the side; for larger bits, they can be thought of as more long-term ideas that can be discussed over a whole year if necessary... small accepted proposals also provide a mechanism for onboarding new developers to the compiler. I don't think we should try to be too strict about conformance to the roadmap.

@mark-i-m

At a high level, the idea is to make the Rust team the bottleneck in the RFC process.

In what sense is it not already? It's my distinct feeling that the bottleneck for T-lang proposals is T-lang itself.

@mark-i-m

There is always a Rust team member up to date on the discussion

Is there an inherent value to this? I don't need to be fully up to date on proposals that we don't have time to consider right now... But I do try to read up on things before meetings if something is nominated.

@mark-i-m

If nobody on the team champions the proposal for 2 weeks, it is closed automatically by rfcbot.

How is an RFC championed? You noted above that rfcbot assigns a member... I think that for T-lang this will just mean that I will champion every RFC...

@mark-i-m

But in part I think Rust as a project has reached a level of maturity where we need to slow down the pace a bit, and part of that is raising the bar for new proposals IMHO.

Also discussed in: Raising the bar for introducing new syntax I personally don't think we need to slow down or raise any bars; in fact, I'm trying to speed up language design to fix inconsistencies and to align with the work on Chalk.