summaryrefslogtreecommitdiff
path: root/doc/development/writing_documentation.md
diff options
context:
space:
mode:
authorGrzegorz Bizon <grzegorz@gitlab.com>2018-02-22 12:09:27 +0000
committerGrzegorz Bizon <grzegorz@gitlab.com>2018-02-22 12:09:27 +0000
commit011ddb51b40897bc13a75d78c9e992f559cbde48 (patch)
treed2f25aa76ab1466ecca82d2cf07e3594b8d7addc /doc/development/writing_documentation.md
parenta75cce1febf0403d66631841fff3bfbeefbfe6e3 (diff)
parenteb421c88ee2a57a437b9b14ba7447a04720354ac (diff)
downloadgitlab-ce-011ddb51b40897bc13a75d78c9e992f559cbde48.tar.gz
Merge branch 'master' into 'backstage/gb/build-stages-catch-up-migration'
# Conflicts: # db/schema.rb
Diffstat (limited to 'doc/development/writing_documentation.md')
-rw-r--r--doc/development/writing_documentation.md29
1 files changed, 18 insertions, 11 deletions
diff --git a/doc/development/writing_documentation.md b/doc/development/writing_documentation.md
index 2a1d744668b..403c9d08752 100644
--- a/doc/development/writing_documentation.md
+++ b/doc/development/writing_documentation.md
@@ -240,7 +240,7 @@ Suppose there's a process to go from point A to point B in 5 steps: `(A) 1 > 2 >
A **guide** can be understood as a description of certain processes to achieve a particular objective. A guide brings you from A to B describing the characteristics of that process, but not necessarily going over each step. It can mention, for example, steps 2 and 3, but does not necessarily explain how to accomplish them.
-- Live example: "GitLab Pages from A to Z - [Part 1](../user/project/pages/getting_started_part_one.md) to [Part 4](../user/project/pages/getting_started_part_four.md)"
+- Live example: "[Static sites and GitLab Pages domains (Part 1)](../user/project/pages/getting_started_part_one.md) to [Creating and Tweaking GitLab CI/CD for GitLab Pages (Part 4)](../user/project/pages/getting_started_part_four.md)"
A **tutorial** requires a clear **step-by-step** guidance to achieve a singular objective. It brings you from A to B, describing precisely all the necessary steps involved in that process, showing each of the 5 steps to go from A to B.
It does not only describes steps 2 and 3, but also shows you how to accomplish them.
@@ -254,18 +254,25 @@ through the process of how to use it systematically.
#### Special format
-Every **Technical Article** contains, in the very beginning, a blockquote with the following information:
+Every **Technical Article** contains a frontmatter at the beginning of the doc
+with the following information:
-- A reference to the **type of article** (user guide, admin guide, tech overview, tutorial)
-- A reference to the **knowledge level** expected from the reader to be able to follow through (beginner, intermediate, advanced)
-- A reference to the **author's name** and **GitLab.com handle**
-- A reference of the **publication date**
+- **Type of article** (user guide, admin guide, technical overview, tutorial)
+- **Knowledge level** expected from the reader to be able to follow through (beginner, intermediate, advanced)
+- **Author's name** and **GitLab.com handle**
+- **Publication date** (ISO format YYYY-MM-DD)
-```md
-> **[Article Type](../../development/writing_documentation.html#types-of-technical-articles):** tutorial ||
-> **Level:** intermediary ||
-> **Author:** [Name Surname](https://gitlab.com/username) ||
-> **Publication date:** AAAA-MM-DD
+For example:
+
+
+```yaml
+---
+author: John Doe
+author_gitlab: johnDoe
+level: beginner
+article_type: user guide
+date: 2017-02-01
+---
```
#### Technical Articles - Writing Method