- to the issues about the problems being solved;
- to the issue about the motivation for this RFC;
- to a discuss thread (or multiple such threads) for discussing the RFC itself;
- perhaps multiple threads, with summaries given where relevant;
- if the RFC is accepted, a link to the final text in the repo itself;
- if the RFC is not accepted, a link to the final rational
While in general I sympathize very much with all of this, I will say: some kind of central user interface as suggested above needs to exist, and the design of such an interface needs to be very carefully considered, or it will be even harder to understand RFCs than it is today. The downsides to GitHub-driven RFCs are fairly well-known in general and are well-summarized by @aturon at the top of the thread; but the upside is that there is one canonical source of truth for that RFC.
That said, if we have API-type access to all the relevant places where the discussion happens (Discourse threads, relevant GitHub issues indicating problems, etc.) in such a problem tracker, along with (perhaps?) a CMS-style interface for the shepherds to use for summarizing status, that could be a real win.