diff --git a/rdd-technical-reference.md b/rdd-technical-reference.md
index da4cd07a8147dd6c03207ff1cbd179b812bf47d3..489617d9dc143037dfbce31a72c4273787a5e0bc 100644
--- a/rdd-technical-reference.md
+++ b/rdd-technical-reference.md
@@ -201,7 +201,7 @@ This may encompass:
> There is external documentation that is accessible and sufficient for an expert user to configure and use the
software for the user’s individual needs. Terminology and methodology is not explained.
-###### Actions to Be Taken in RDD
+##### Actions to Be Taken in RDD
- a README(.md) has to be available in the source code repository (cf. [General Notions about
Documentation](#general-notions-about-documentation))
@@ -213,7 +213,7 @@ Documentation](#general-notions-about-documentation))
> There is a user manual that can guide a reasonably skilled user through use and customisation of the software to the
user’s individual requirements. Documentation is consistent with current version of the software.
-###### Actions to Be Taken in RDD
+##### Actions to Be Taken in RDD
- a more detailed explanation is available for the user at some place (such as user guide in wikis, etc. pp.)
- docs should also be provided in a `docs` directory in the source code repository
@@ -289,34 +289,34 @@ Ideally, we use build tools to conveniently get a software running.
The reason for using a build tool is to be able to build and/or test a code project with one command (after checking
out). Another reason is to include dependency management.
-##### Build tools we are using at the moment
+#### Build tools we are using at the moment
-* **bash scripting**: (bdnPrint, FontanePrint)
-* **eXist**: Ant (SADE)
-* **Java**:
+- **bash scripting**: (bdnPrint, FontanePrint)
+- **eXist**: Ant (SADE)
+- **Java**:
- Maven (TextGrid)
- gradle (TextGrid)
-* **JavaScript**:
+- **JavaScript**:
- bower (DARIAH-DE GeoBrowser, tgForms)
- cake (tgForms)
- NPM (DARIAH-DE Publikator, tgForms)
- rake (DARIAH-DE GeoBrowser)
-* **Python**:
+- **Python**:
- make (Sphinx documentation)
- PIP (DiscussData)
-* **Ruby**: bundler (DARIAH status page)
+- **Ruby**: bundler (DARIAH status page)
### Packaging
#### CESSDA's Software Maturity Levels in RDD (CA5)
-###### MUST
+##### MUST
`MUST` be SML5, which is defined as follows:
@@ -325,7 +325,7 @@ packaged/containerised software. Administrators are notified if deployment fails
upgraded/rolled back from a Continuous Integration server job (or equivalent). Data and/or index files can be restored
from a Continuous Integration server job (or equivalent).
-###### Actions to Be Taken in RDD
+##### Actions to Be Taken in RDD
- examples for versions of deployed software: versioning of deb packages
- examples for rollback: rebuild index ElasticSearch from source data, restore database backup
@@ -337,24 +337,24 @@ and test-coverage for your default-branch under Settings/General->Badges.
The generic links for all projects are:
-* Pipeline-status
+- Pipeline-status
- Link: `https://gitlab.gwdg.de/%{project_path}/commits/%{default_branch}`
- Badge image URL: `https://gitlab.gwdg.de/%{project_path}/badges/%{default_branch}/pipeline.svg?style=flat-square`
-* Test-coverage
+- Test-coverage
- Link: `https://gitlab.gwdg.de/%{project_path}/commits/%{default_branch}`
- Badge image URL: `https://gitlab.gwdg.de/%{project_path}/badges/%{default_branch}/coverage.svg?style=flat-square`
The workflows we are using currently in Jenkins and GitLab Runner are:
-* Code building
-* Testing
-* Code analyzer (Sonar)
-* Packaging (JAR, WAR, DEB, XAR)
-* Distribution (Nexus, APTLY repo, eXist repo)
-* Release Management (via GitLab Environments and gitflow)
+- Code building
+- Testing
+- Code analyzer (Sonar)
+- Packaging (JAR, WAR, DEB, XAR)
+- Distribution (Nexus, APTLY repo, eXist repo)
+- Release Management (via GitLab Environments and gitflow)
#### Sample Configuration of the GitLab Runner
@@ -403,11 +403,11 @@ from the server in the influxdb.
Some system statistics monitored by telegraf in our current puppet setup:
-* CPU
-* Memory
-* Space
-* Apache
-* ...
+- CPU
+- Memory
+- Space
+- Apache
+- ...
Telegraf collects statistics with input plugins. A list of plugins is
[available](https://github.com/influxdata/telegraf#input-plugins).
@@ -461,7 +461,7 @@ Best practice is to maintain a file listing all third-party packages that are
part of the software. This list should hold the following metadata and `SHOULD` be
prepared like the table below, always in alphanumeric order.
-```
+```nat
| name | license | origin |
|------|---------|--------------------|
| foo | barware | github.com/foo/bar |
@@ -469,9 +469,9 @@ prepared like the table below, always in alphanumeric order.
Maybe the `license-maven` plugin will help you.
-### CESSDA's Software Maturity Levels in RDD (CA2)
+#### CESSDA's Software Maturity Levels in RDD (CA2)
-###### MUST
+##### MUST
`MUST` be SML5, which is defined as follows:
@@ -481,7 +481,7 @@ in the source code of the product, in the documentation, and in the expression o
intellectual property rights statements are expressed in legal language, machine-readable code, and in concise
statements in language that can be understood by laypersons, such as a pre-written, recognisable license.
-###### Actions to Be Taken in RDD
+##### Actions to Be Taken in RDD
- see rdd-technical-reference for choosing the license
- source code: use OSI approved licenses? (see <https://opensource.org/licenses)> (++TODO discuss in fe-develop++) (how
@@ -495,7 +495,7 @@ file called COPYING [see <https://www.gnu.org/licenses/gpl-howto.de.html>] other
(<https://softdev4research.github.io/4OSS-lesson/03-use-license/index.html#add-a-licence-file-to-a-repository)>
- in the source code header the license statement is added to every file. GPL example:
-```
+```nat
This file is part of FOOBAR.
FOOBAR is free software: you can redistribute it and/or modify