[chairleader]

Thanks for this link, I agree, that is a fantastic framework for documenting software.

The idea that a reader of a piece of documentation is approaching it with a particular goal is spot on. I suppose I envision either more or perhaps another layer of goals/contexts in addition to what this is outlined here.

A set of use cases I'm thinking of involve the process of changing what a piece of software does. As design documents arise that may or may not apply to a future version of the software, where should that live? Perhaps during the design phase of that release it belongs in one place while designers are iterating on its contents, and later it moves to another place when it is considered a stable reference document?

Plenty of capital P Process behind this question, I suppose. And perhaps there's no getting around some amount of the "librarian" work moving content around to reflect its use.

[_kb]

MADR [1] in its reframed "Any Decision Record" form can be a good tool for that. RFDs [2] also appear to capture a similar intent.

[1]: https://adr.github.io/madr/

[2]: https://rfd.shared.oxide.computer/rfd/0001