CHANGELOG.md

+# [2.14.0](https://gitlab.gwdg.de/fe/technical-reference/compare/v2.13.0...v2.14.0) (2024-01-09)
+
+
+### Features
+
+* add recommendations on docs-as-code ([01d1b29](https://gitlab.gwdg.de/fe/technical-reference/commit/01d1b29dfa56f2af871cb4bde300ec77727f45a1))
+
 # [2.13.0](https://gitlab.gwdg.de/fe/technical-reference/compare/v2.12.2...v2.13.0) (2024-01-09)
 
 

chapters/development/documentation.md

@@ -65,6 +65,17 @@ Then add (if applicable):
 - links to the relevant issue tracker/project management systems, and
 - badges to CI status.
 
+###### Docs-as-code
+
+Documentation `SHOULD` be placed within the software repository.
+Furthermore for the documentation writing, building, testing and publication process, all quality criteria, workflows
+and pipelines `SHOULD` be set up alike those for the software itself.
+In this way documentation is treated the same way as code including the usage of version control, issue tracker,
+code reviews and automated tests.
+
+A presentation of the usage of this approach for a long-term scientific software project is available at [zenodo](https://zenodo.org/records/7260347).
+In general, this approach can be applied to small-scale projects as well.
+
 ##### Doc Sprints
 
 To ensure thorough documentation of our code doc sprints or other meetings specifically targeted at writing docs can be organized.
@@ -73,7 +84,7 @@ To ensure thorough documentation of our code doc sprints or other meetings speci
 
 ###### Software Architecture
 
-Each software project `SHOULD` provide an architecture diagram that helps to understand its basic functionality.
+Each software project `SHOULD` provide an architecture diagram that represents its major components and their interaction.
 In some cases using tools to generate diagrams such as UML class diagrams may not be possible.
 
 *Examples:*