From fdb06c934897cf8459ab84d7b044dce63dce3078 Mon Sep 17 00:00:00 2001
From: Martin Schroschk <martin.schroschk@tu-dresden.de>
Date: Fri, 20 May 2022 07:35:01 +0200
Subject: [PATCH] Move writing style topwards
---
.../docs/contrib/content_rules.md | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/doc.zih.tu-dresden.de/docs/contrib/content_rules.md b/doc.zih.tu-dresden.de/docs/contrib/content_rules.md
index caa069dbf..63685d203 100644
--- a/doc.zih.tu-dresden.de/docs/contrib/content_rules.md
+++ b/doc.zih.tu-dresden.de/docs/contrib/content_rules.md
@@ -53,6 +53,25 @@ or via [Email](mailto:hpcsupport@zih.tu-dresden.de).
## Detailed Overview
+### Writing Style
+
+* Assume that a future reader is eager to start typing commands. Thus, encourage the reader by
+ addressing him/her directly:
+ * Example: Use `You can/should ...` instead of `Users can/should ...`
+ * Example: Use `Your contribution is highly welcome` instead of `Contributions from user-side
+ are highly welcome`
+* Be brief! Provide the main idea/commands first, special cases later. If it is not necessary to
+ know how a special piece of software works, don't explain it.
+* Provide the often-used commands first.
+* Use active over passive voice
+ * Write with confidence. This confidence should be reflected in the documentation, so that
+ the readers trust and follow it.
+ * Example: `We recommend something` instead of `Something is recommended.`
+* Capitalize headings, e.g. *Exclusive Reservation of Hardware*
+* Give keywords in link texts, e.g. [Code Blocks](#code-blocks-and-syntax-highlighting) is more
+ descriptive than [this subsection](#code-blocks-and-syntax-highlighting)
+* Avoid using tabs both in markdown files and in `mkdocs.yaml`. Type spaces instead.
+
### Pages Structure and New Page
The documentation and pages structure is defined in the configuration file
@@ -162,25 +181,6 @@ for a comprehensive overview.
side is displayed. The block is open by default if `???+` is used. Long code examples should be
folded by default.
-### Writing Style
-
-* Assume that a future reader is eager to start typing commands. Thus, encourage the reader by
- addressing him/her directly:
- * Example: Use `You can/should ...` instead of `Users can/should ...`
- * Example: Use `Your contribution is highly welcome` instead of `Contributions from user-side
- are highly welcome`
-* Be brief! Provide the main idea/commands first, special cases later. If it is not necessary to
- know how a special piece of software works, don't explain it.
-* Provide the often-used commands first.
-* Use active over passive voice
- * Write with confidence. This confidence should be reflected in the documentation, so that
- the readers trust and follow it.
- * Example: `We recommend something` instead of `Something is recommended.`
-* Capitalize headings, e.g. *Exclusive Reservation of Hardware*
-* Give keywords in link texts, e.g. [Code Blocks](#code-blocks-and-syntax-highlighting) is more
- descriptive than [this subsection](#code-blocks-and-syntax-highlighting)
-* Avoid using tabs both in markdown files and in `mkdocs.yaml`. Type spaces instead.
-
### Spelling and Technical Wording
To provide a consistent and high quality documentation, and help users to find the right pages,
--
GitLab