@nikomatsakis Having somebody curate the discussion is a noble idea, but I suspect that enforcement of that policy would be hard. But maybe the difficulty is a good lever for making under-motivated RFCs go away more quickly. If nobody is willing to maintain the summary then it’s clearly not important enough, and a bot can auto-close it.
I also though think that the summary of the discussion belongs in the RFC. When I come to an RFC PR with hundreds of comments I expect to be able to read the RFC to understand the state of the proposal. The RFC should contain an up-to-date consensus design, and all the dissent should be recognized in the alternatives and open questions sections.
Just a quick elaboration on my previous comment. I might expect that after each ‘round’ of debate - where the discussion tends to be overwhelming and only interesting to those most deeply involved - somebody must update the RFC text to reflect everything notable from the debate. Then people less involved, including many of those who have to make a decision, just have to re-read the RFC.
It bugs me a lot to read RFCs where the design is obviously underspecified, and the alternatives and open questions sections are neglected.
I definitely feel like the “alternatives” section seems like one of the most critical in the RFC, and it should document any remotely credible idea for the record, along with pros and cons compared to the proposal in the RFC. Adding summary comments in the RFC discussion on Github helps clarify the state of the discussion, and gives people an opportunity to say “no, I meant something different” or “I have a different issue”. However, the consensus record of the discussion absolutely belongs in the RFC.