I don't understand why one-implementation language project would need RFCs, other than to inflate their sense of self-importance.
RFCs are useful in a multi-vendor situation. They are permanent documents the constitute a kind of standard. For instance internet RFCs, or Scheme SRFIs.
If the rest RFC is something you jettison once it implemented, then it's actually something that belongs in a bug database as a feature request, which can be marked closed when done (after which nobody ever looks at it again except as a historic reference). Someone implementing the same thing in a new implementation would not be looking at it, but at the real documentation (which was written as part of implementing the ticket, and maintained afterward).
> I don't understand why one-implementation language project would need RFCs
For multiple reasons. First, because it's not actually obvious from a PR what the overall design and big picture is. And second, because we want to decide about that design and big picture before someone does too much implementation work, lest that work need redoing because the design changed (or lest that work go to waste because we rejected the RFC).
RFCs are useful in a multi-vendor situation. They are permanent documents the constitute a kind of standard. For instance internet RFCs, or Scheme SRFIs.
If the rest RFC is something you jettison once it implemented, then it's actually something that belongs in a bug database as a feature request, which can be marked closed when done (after which nobody ever looks at it again except as a historic reference). Someone implementing the same thing in a new implementation would not be looking at it, but at the real documentation (which was written as part of implementing the ticket, and maintained afterward).