Pre-meta-RFC: rate limiting the firehose

[mark-i-m]

So regarding GitHub vs Discord etc. I see a few major benefits to GitHub, which is why my leaning is toward trying to tame the madness rather than switch to something else:

• Everyone is already on GitHub, whereas requiring a login to another platform will be a paper cut for new contributors. We already have GitHub, users.rlo, internals.rlo, discord, zulip... Keeping it on Github means less fragmentation
• GitHub is good for record keeping. It is not a chat platform, whereas all the others are. This is a good thing IMHO because it means that discussions are easier to read after the fact (even if GitHub does have its own UI problems). Even the form of discussion will be slightly different. I'm worried that switching to an actual chat platform will cause RFC discussions to be come very chatty/noisy and impossible to follow after the fact.
• GitHub allows cross-linking easily. This is useful for documentation purposes.

IMHO, GitHub is actually not that bad. We just need to find ways of keeping it productive and scaling it to larger discussions.

---

@Centril

I think @H2CO3 summarized my main point well. I'm not trying to stop RFCs -- just rate-limit them a bit to what we can actually manage. I do think we are going a bit fast at designing and not fast enough at polishing and stabilizing.

I am not convinced that having new features in every release is a good thing. I would like it to be more like every third release or something... not by artificially slowing down stabilizations, but simply by having fewer things to stabilize. I suspect we might just disagree on this point.

@Centril

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.

@Centril

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?

Let me clarify: my observation is that many features are blocked on (a) fcp merge for RFC; (b) implementation; or (c) fcp merge for stabilization. I propose we move this "blocking" up front: an RFC doesn't get even get discussed on the RFCs repo unless the appropriate team has allocated bandwidth to shepherd implementation all the way to stable. (Discussions are, of course, welcome elsewhere).

@Centril

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…

@Centril

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.

My point is mostly that there should be some human assigned to every RFC. How the teams do that is up to them. Random is the lowest-effort strategy I could think of, but it's just an idea.

I leave that up to discussion