You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2024. It is now read-only.
For a few months, I have been a mild advocate of Diátaxis. It is a set of guidelines which help write useful "documentation". TL;DR; it divided what constitutes documentation as a whole in 4 parts:
Tutorials
How-to guides
Conceptual guides
Reference guides
I find it quite useful and I may propose to aim for not just one ReSpec (side note, is bikeshed an option?) but up to four.
Specifically, a Reference guide would be more or less a vocabulary listing with ranges, domains, etc, and simple examples. Next, I would go for How-Tos to elaborate on using the spec to accomplish practical goals. Conceptual guides would also be useful, to discuss some design choices, etc. We may choose not to go for tutorials at all IMO...
The text was updated successfully, but these errors were encountered:
IMH experience yes, I would decouple the reference documentation, hands-on how-tos tutorial, and an architecture documentation expliciting the design choices.
For a few months, I have been a mild advocate of Diátaxis. It is a set of guidelines which help write useful "documentation". TL;DR; it divided what constitutes documentation as a whole in 4 parts:
I find it quite useful and I may propose to aim for not just one ReSpec (side note, is bikeshed an option?) but up to four.
Specifically, a Reference guide would be more or less a vocabulary listing with ranges, domains, etc, and simple examples. Next, I would go for How-Tos to elaborate on using the spec to accomplish practical goals. Conceptual guides would also be useful, to discuss some design choices, etc. We may choose not to go for tutorials at all IMO...
The text was updated successfully, but these errors were encountered: