Refining RFCs part 2: RFC staging

Just wanted to mention a couple more current “pain points” which are sort of complementary to the “it’s hard to get caught up with RFC discussions due to their length” problem:

  • When discussion of an idea or proposal keeps moving to new threads (discourse, issue tracker, RFC postponements followed by new RFCs), thoughts I’d expressed in one of the earlier iterations are often still just as relevant, but now essentially lost as most people don’t go back to read earlier discussions (if they even know about them). Having to re-express the same thoughts all over again every time a new thread is started is exhausting, and starts to make it feel like a contest of stamina rather than a discussion about ideas. (The most egregious example of this was/is the “impl Trait” feature.)

  • When a discussion thread gets long enough, it often happens that someone doesn’t have time to read the whole thread, but still wants to propose an idea or ask a question that seems “obvious” to them. Which just happens to be the same idea that’s been brought up in that thread, in the same fashion, 50 times beforehand. (Examples: “why can’t we just use fn foo<T>() -> T for abstract output parameters”; “why can’t we just optimize Box::new instead of adding a placement operator”.) Which then exacerbates the original issue by making the thread even longer. (Under the existing regime, all solutions to this problem are bad: either you erect an unreasonable barrier to entry for discussing RFCs by forcing everyone to read miles of discussion before commenting themselves, or you burden everyone else with the consequences when people don’t and then keep independently bringing the same ideas up over and over.)

All of these problems (including the originally-mentioned ones) seem to motivate the same kind of solution: having some kind of persistent document/page/site where the ideas, arguments, and counterarguments are mapped out, according to their logical or topological relationships, “once and for all”; and this would be grown and fleshed out as discussion progresses. (Which sounds broadly similar to the “Problem Tracker” described in the blog post.) But doing this “right”, or even “good enough” seems nontrivial: Who gets the right to edit these pages? How are the ideas even laid out – as a linear text document (with its attendant drawbacks), or as some kind of nonlinear tree or graph structure (laid out how)? You can’t even reliably silo off particular “big-ticket items” or “problem areas” from each other, the problems and/or their solutions are very often interrelated. (For example.) (Maybe the best solution to this last problem would be to employ a sophisticated device, known as the “hyperlink”; like a wiki, if not actually a wiki.)

2 Likes