I wonder how to handle RFCs. There should certainly be a link to the RFC, and if we have that, it might be better to reduce the duplicate content to just a sentence or two (but I'm not sure). I actually don't even see any information whether changing RFCs will be done in-place (seems preferred, as we have version control) or by issuing replacements under new numbers (like IETF RFCs).

cc @zimbatm, @grahamc, @teh, @moretea, @peti, @edolstra, @domenkozar, @FRidh on how to handle the RFCs => documenting them in the manual, amending rfcs in the repo or writing new rfcs that obsolete old ones?

Immutability: perhaps it would be best to make them explicitly versioned, e.g. RFC 15.1 or something. My experience with IETF RFCs is that all those different numbers are hard to remember, so I'd prefer to minimize their amount, say that "15.x" will describe our release managers forever...

I see RFCs mainly as a communication tool that helps us reach consensus on bigger items. Once a RFC has been merged it means that we agree on the direction and the implementation should happen elsewhere. I don't think that the RFC should be mutated afterwards, except to correct metadata (to add the forward-reference to the implementation PR).

What it means in practice is that usually the body of the proposal contains useful information that would get duplicated elsewhere and keep evolving in the repo where the actual work is happening. In that regard the RFC would only be useful as a reference shortly after the RFC has been accepted.

Back-references to the RFC aren't really necessary. I would probably only reference it in the implementation PR to help reviewers understand the context but that's it.

If the work to implement an accepted RFC involves documentation, then that should be added to the relevant manual. The RFC's themselves are just to achieve consensus in the community on what to do exactly without starting the work itself.

IMHO, if a new RFC obsoletes (part of) an existing RFC, the PR for the new one should add some note to the top of the existing one to make sure that readers are aware that some parts are outdated.

If the RFCs are/were just temporary things to discuss about and achieve consensus, I don't much understand why a formal-like document is actually created in the process.

EDIT: my perception might have been biased by having studied lots of IETF RFCs.

The RFC term is a bit too overloaded so it might create some confusion. The format is useful to force the discussion in a productive way. It encourages a proper problem statement, proposed implementation and ensures that research has been done. With that in hand, the reader would then ideally have enough context to form his own opinion. Otherwise we have the issue where things are being discusses in a bunch of places and not everybody has read the same things so we haven't all explored the same branches of the decision tree.

Anything preventing this to be added to the manual? ^{Other than the merge conflict}

Are there any updates on this pull request, please?