Hey -- I gave the RFC (rfc#2850) a quick read this morning. Overall, I'm quite positive, but I'd like to make a meta-note: this rfc thread is getting really long! So far it strikes me as mostly some high quality questions and answers.

I'm wondering though best to manage it. Perhaps things are just fine here, but one idea I've been toying with for longer threads is to close the RFC periodically and collect the questions etc into a FAQ and summary, and then open a new RFC that starts with that summary. The hope would be that people who come to the RFC would be able to quickly pick up the context and avoid repeat questions, and that it would be RFC authors a bit of time to catch up on people's questions and integrate any changes they plan to make.

That said, it may not be necessary in this case. =)

I'm curious @Amanieu / @Josh Triplett what you think about this larger question (should we try to "curate" RFC thread at all, to help people get an overview of what's been discussed, and -- if so -- how?)

@Amanieu I absolutely think we should track individual issues in the issue tracker, and use that for cases where we haven't updated the RFC yet.

Discussion living in the issue tracker for longer definitely keeps things under control better. For future tricky RFCs we might want to just immediately say "please do not discuss here, please use the issue tracker at this other place for better threaded conversation"

I'd like to re-open this. I feel like the conversation on rfc#2850 is way more than I can reasonably be expected to digest. :) I think it would be good to close the RFC and try to summarize key points in the discussion thread, personally.

@Amanieu I think the idea is that we close it and until we have a summary we basically say "please hold off on discussing"

I think it might be good to do a retrospective on this new RFC process after it's all finished. I might be an outlier here, but I feel that it didn't reduce the amount of discussion after the RFC was published.

The RFC actually went through several stages of feedback: first the pre-RFC thread on internals, then the project group and finally the published RFC.

I'm aware of all of those stages. I even participated in some of them. One Discourse thread, and then a github repo with 6/10 issues resolved, and three PRs to the files.

I maintain that it was insufficient prep work for something of this scale, and that requires as much detailed specification as this does.

Basically because discussion on a PR thread is a terrible way to manage topics and allow people to go through it later to catch up on what has been talked about. That's why it should be Zullip or GitHub Issue based for much longer.

To be fair, at the point where I decide to publish the RFC, there were no more outstanding issues on both zulip and the github repo, and discussion seemed to have somewhat died down.

Moving from internals to Zulip/Github left a number of open questions behind. Were all of those posed again, or left unanswered? Determining an answer to that question seems to require going through both threads manually which is a huge undertaking of its own.

We talked about the RFC thread in the lang team meeting today. We definitely felt that the current thread would benefit from a summary post (covering all outstanding issues), along with making sure the alternatives section of the RFC is complete with respect to things raised in the thread.

@nikomatsakis suggested, and I'm starting to agree, that due to limitations in GitHub we might want to close the RFC PR and open a new RFC PR, to draw a line under the discussion so far and help people start fresh.

By alternatives section, do you mean unresolved questions section?

Unresolved questions, and the Alternatives part of Rationale and Alternatives.

Effectively, any outstanding reasonable comment that we don't fix by changing the RFC should be documented either as an unresolved question (if we want to defer it to the implementation phase to answer) or under rationale and alternatives (if we want to say "we could do it differently, but we don't think that's the right approach, and here's why").

Working on that now. :)

Trying to figure out the right next step there.

@Josh Triplett Sorry about taking so long to do this, I'm working on writing up a summary now. Do we want to encourage people to comment on a new RFC thread (open a new PR on rust-lang/rfcs) or should we point them to use the issue tracker of the asm project group instead?

I'm not exactly sure what to write for the summary though. I triple checked all comments on the RFC and made sure everything was addressed in the RFC text.

Then the summary should say exactly that, that all comments above this point have been Incorporated into the RFC. And you should link that summary from the top message. You should then mention that as requested you're opening a new thread to make it easier for people to follow.

I don't think that you, Amanieu, specifically did anything wrong, because you were clearly told to restart the RFC, but I think the idea to restart the RFC was a poor one (for essentially the reasons stated in that comment).