Another «is it a good idea?» incremental question: amend the RFC process «soon» so that the detailed design MAY be replaced in part or completely with a list of PRs. Eventually consider whether all process changes SHOULD have their detailed design be a link to a PR against documentation.
In the PR I already changed the wording in the direction of having implementation work done earlier. (Previously the document stated “get merged first then do implementation”, which currently is more the exception than the rule.) I’m not sure that enforcing this is applicable to all RFCs, and the implementation PRs are not guaranteed to cover all ground of the “detailed design” section so we’d still need that.
Some RFCs have pretty trivial implementation (e.g. change a line in the tier list file) that can be done at any time, others have some complex multi-step procedures that may have to be done at specific points in time and cannot easily be prepared in advance (e.g. treewide Nixpkgs refactorings or migrations). Yet others have the implementation work spread out across time and contributors without time constraints, like RFC 42 or the unstable version attributes.
One thing that I considered was adding some words about that the RFC should (or may) describe the implementation process, i.e. who is responsible for doing what and when. But this too would only have been applicable to only a subset of RFCs.
Agreed; that’s why I only consider «should» (of course not «must») for process changes (and say that sometimes the PR replaces only a part of detailed design).
Maybe it is better to say that detailed design may be externalised to PRs against documentation specifically? Prototypes are a separate question.
— basically looking for the minimal process change where this comes cheaper.
Oh, I see what you’re going for here, that’s an interesting idea. Here too I don’t think it would be applicable in all situations—usually the RFC describes things relative to the current state, while the documentation then of course stands for its own—, but I can try to add a sentence that encourages treating documentation as part of the implementation work.
I am asking indeed if it is a good idea to explicitly make a change in the process (where it becomes acceptable that the detailed design describes only the target state, and — maybe partially — lives in a separate PR).
I do value that your PR is very careful about clarifying and including best practices but not making process changes! This also means that this idea of mine will only make things worse in the context of that PR.