Evaluate improvements to the RFC system

[ehuss]

Evaluate improvements to the RFC decision process, such as tracking and supporting multiple potential outcomes and changes in people's preferences without restarting decisions, and providing lighter-weight mechanisms for reversible decisions.

The RFC process itself can be grueling and stressful. Is there some way to improve that?

Should management of the RFC repo itself (like rust-lang/rfcs#3339) be the responsibility of the Leadership Council?

Should there be an issue tracker (see rust-lang/core-team#26)?

Currently @ehuss manages the RFC repo (such as tracking assignments, dealing with build and CI issues, etc.), just because they randomly decided to take on that responsibility. Should that be formalized? Can we find others to help?

I'm sure there are many other questions and concerns.

[ehuss]

Comment from @yaahc on Zulip:

improving feedback loops around the RFC process and similar proposal oriented processes. I think we could do a better job of asking RFC authors, both for merged RFCs, and perhaps more importantly for stalled and closed RFCs, how the process was for them, what worked well for them and what didnt.

[ehuss]

One concept that I would like to see iterated on more is that for large RFCs to start with a GitHub repo where individual issues and documents can be hashed out. The GitHub PR interface does not handle threading very well, and PRs with hundreds of comments are overwhelming and difficult to navigate.

Some examples are https://github.com/Manishearth/namespacing-rfc and https://github.com/rust-lang/wg-cargo-std-aware.

Similar to that, I think breaking down large RFCs into smaller decisions could help with making incremental progress. For example, starting with a statement of intent to tackle something, but not diving into the details too much. Then moving on to prototyping and experimenting, and collecting feedback. Then once things are approaching some steady state make a final proposal to stabilize. Perhaps there can be additional smaller steps added throughout this process.

[ehuss]

Brought up in https://rust-lang.zulipchat.com/#narrow/stream/392734-council/topic/Nominating.20issue.20for.20discussion, the current system does not handle small teams very well. rust-lang/rfcbot-rs#315 proposes to make an at least 2/3 requirement.

Another suggestion in that thread is to allow it to be configurable by team.