Updating docs with notes about documentation.

CONTRIBUTING.md

@@ -33,12 +33,25 @@ See the next section for how to adapt to upstream changes.
 
 ### Branching Strategy
 
-By default development happens in branches, which are merged via pull requests.
+By default, development happens in branches, which are merged via pull requests.
 Special cases, like fixing problems with the CI pipeline, are of course exempt from this guideline.
 
 Please make sure to give branches a meaningful name!
 As an example, the one creating this documentation was called `branching-merging-documentation`.
 
+### Documentation
+
+When a new extension was added (or significant changes were made) please update the documentation.
+To add documentation for an undocumented extension add an entry in the `docs/docs-nav.yml` file and create a new `.adoc` file for the extension.
+To ensure that a linebreak is properly displayed in the resulting documentation ensure to write **one and only one sentence per line**.
+This rule also applies for very short sentences like _"Tests must be fast!"_.
+If long as text blocks are not separated by an empty line, they are treated as one paragraph and without line breaks, regardless existing ones. This means you need to apply at least an empty line if you want to have text separated.
+
+For further information regarding formatting, and how to use AsciiDoctor please use the [Writers Guide](https://asciidoctor.org/docs/asciidoc-writers-guide/).
+
+Do **not** update the `release-notes.md` file!
+This file will be generated automatically.
+
 ### Commits
 
 While it is nice to have each individual commit pass the build, this is not a requirement - it is the contributor's branch to play on.