rfcbot to make Github-based design discussions more manageable. This proposal is the confluence of a few different parts. I know that this proposal will likely give people a “what?! you’re kidding!” reaction, so please hear me out.
I propose the following changes (motivated and explained further down):
- 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.
- rfcbot then asks the poster to identify a team to assign the RFC to. The RFC thread is locked until the OP responds with a team. The rfcbot then assigns the RFC to a member from the team to be the RFC’s shepherd.
- A member of the Rust team (or the OP?) may issue a
notecommand 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.
- At most C comments can occur between
notes. 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.
- Individuals and interest groups are encouraged to discuss proposals on their own repos or on internals before posting the RFCs repo.
- The Code of Conduct is updated to explicitly state that it is considered poor etiquette to comment without making a good-faith effort to read and understand the ToC. Repeat offenders may be evicted.
This proposal aims to address the following problems
- 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.
- Lengthy RFC discussions are hard to read on GitHub. This is because
- GitHub collapses comments in the middle
- GitHub marks all notifications read if you visit a thread once
- Discussion on review comments don’t appear at the end of the thread, so it is easy to miss discussions because you are only following the end of the page.
- Summary comments get lost easily in the flood.
- 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.
- Many people comment without reading. I can’t blame them. Catching up on a long thread is rather hard. However, this means that issues tend to get brought up multiple times, compounding the problem.
- Many proposed features don’t fit clearly into the roadmap.
At a high level, the idea is to make the Rust team the bottleneck in the RFC process. This is counterintuitive but intentional: if a Rust team member doesn’t have the bandwidth to keep up, I hypothesize that very few others in the Rust community will have the bandwidth, except those biased by a strong interest in the particular feature.
In contrast, by having a Rust team member there the whole time:
- A proposal has somebody to shepherd it to the finish line (stabilization).
- There is always a Rust team member up to date on the discussion
- High-quality summary posts (the ToC) get generated as a side-effect of the discussion.
- The RFC process is rate-limited to something that can be sustained.
- Discussion of less complete proposals gets pushed to other media (e.g. internals or other repos).
Note that this proposal is not intended to produce more stress or workload for team members. Rather, we make it the new norm for team members to say “we don’t have bandwidth” or “this doesn’t fit into the roadmap”, which is already the case for many RFCs. If nobody on the team champions the proposal for 2 weeks, it is closed automatically by rfcbot.
Wow. This seems draconian.
Yes, I realize that. In part, I am trying to be controversial enough to start a discussion. 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.