I don’t think any form of non-public comment would be an improvement for the RFC process, or help with the problem of overly long comment threads. Personally, a deliberation period would encourage me to be silent until it’s over, or to only submit relatively simple comments that don’t take a lot of effort to write.
It sounds like part of the premise of this proposal is that many people take a long time to form their opinion on an RFC and are then discouraged by the length of the discussion generated while they were forming that opinion. While probably true to some extent, there’s clearly also a ton of people that form an opinion very quickly or simply post without attempting to read the entire discussion (to be clear, I am not implying either of these are a bad thing) or actually are willing to read the entire comment thread. I think a deliberation period would discourage some of the people who do post today and encourage some of the people who don’t. We simply don’t know if that would be a net win for participation. Even if it is a win for net participation, I would expect a drop in “high quality participation” (actual new ideas or arguments rather than repeats or "I agree"s) precisely because we can’t see what’s been said so far, and a smaller audience (at least to me) incentivizes less effort per post.
We are talking about a small minority of RFCs though. The vast majority of them are just fine with a single comment thread, because the volume of commentary is low enough that everyone who cares can easily read or at least skim all of it. Plus, in my experience, the minority where the comments get out of control (in number, not in content) often have some unique issues that don’t apply even to other hyper-chatty RFCs. For instance, the generators eRFC is the only time I’ve ever seen a large number of RFC comments with very non-concrete/unactionably vague suggestions, or ideas that simply don’t make any sense in a language like Rust. It’s also the only one that I would describe as a history lesson, since it turned out that explaining Rust’s past experiments with other threading models was key to establishing why stackless coroutines was the proposed solution. I think it’s safe to assume these particular issues won’t come up for the NLL RFC, any module system RFC, etc.
But despite all of that, I do agree there’s a problem here. Although I am a crazy person who reads literally every comment on every RFC, it’s ludicrous to expect everyone that’s capable of meaningfully contributing to an RFC discussion to invest that much time before writing their one comment. In my opinion, any solution that theoretically could address this problem would have to fall into one of these categories:
-
Reducing the need to post any kind of feedback at all, by making the RFC “better” at the outset. We already do a TON here. Honestly, I don’t think we can do much better at this category. “Bad RFCs” just aren’t the problem.
-
Reducing the need to post comments by encouraging other forms of feedback. For most RFCs there’s not much we can do here, but for highly subjective ones like the module system threads, a lot of people (myself included) tend to post “I like X but not Y” comments that don’t add any new ideas future commenters need to read before writing their own comments. But when there’s an obvious and easy-to-use form of directly aggregetable feedback separate from the full-blown comment thread, a lot of people would probably use that and thus generate fewer comments, or make the comments they do generate more focused on the new, interesting idea they have than a like/dislike list. I’ve heard this is the main reason Github added “reactions”. Polls and surveys also go under here.
-
Reducing the number of comments newcomers need to read before posting their own.
-
3a) Periodically replacing comment threads with summary comments, so all the relevant information remains available but easier to digest. Typically, this is done by closing the current thread and opening a new one, and the first post of the new thread attempts to be a summary of all past discussion. I believe that’s already the best you can do in a lot of cases. In theory we could do more summarizing and thread rebooting, but as pointed out above, that relies on the shepherd or author doing more work, and it relies on all past/future commenters agreeing the summary is accurate. For highly technical RFCs (NLL? const generics?), this is what I would focus on. For highly subjective RFCs like those involving the module system, this seems completely unrealistic, so I’d instead focus on #2 and #3b.
-
3b) Breaking up the comments/information into subthreads, so newcomers can completely skip the information that’s not relevant to them. Yes, half of the other posts in this thread already suggested this. They’re all right. On the rare, exceptionally chatty RFCs for which a standard RFC thread is not enough, this is by far the best thing we could possibly do to improve the process.
My conclusion: We should give the module system discussion its own github repo. There should be separate issues for every significant problem with the current system and proposed change, so everyone can easily throw +1s and -1s at each individual idea, and comment only if they have something new to add. People can easily make new issues for side discussions or new ideas worth voting on. The repo itself would contain all the strawmen proposals so far and a summary of all ideas and feedback we’ve managed to gather. Issues where some sort of consensus has been achieved (not necessarily on the solution, but at least what the leading candidates and their pros/cons are) then get closed by pull requests which update that summary. Newcomers would only have to read the summary, “vote” on any open issue they have an opinion on, and read the comments only on issues they have a strong interest in. That seems more manageable than catching up on even one of the module threads on these forums today.
