Docs: adere ssot

3 files changed, 61 insertions, 17 deletions

diff --git a/doc/user/project/protected_branches.md b/doc/user/project/protected_branches.md
index 9a3c02e1f50..e3515711f17 100644
--- a/doc/user/project/protected_branches.md
+++ b/doc/user/project/protected_branches.md
@@ -1,3 +1,7 @@
+---
+type: reference, howto
+---
+
 # Protected Branches
 
 [Permissions](../permissions.md) in GitLab are fundamentally defined around the
@@ -9,13 +13,13 @@ created protected branches.
 
 By default, a protected branch does four simple things:
 
-- it prevents its creation, if not already created, from everybody except users
-  with Maintainer permission
-- it prevents pushes from everybody except users with Maintainer permission
-- it prevents **anyone** from force pushing to the branch
-- it prevents **anyone** from deleting the branch
+- It prevents its creation, if not already created, from everybody except users
+  with Maintainer permission.
+- It prevents pushes from everybody except users with Maintainer permission.
+- It prevents **anyone** from force pushing to the branch.
+- It prevents **anyone** from deleting the branch.
 
->**Note**:
+NOTE: **Note:**
 A GitLab admin is allowed to push to the protected branches.
 
 See the [Changelog](#changelog) section for changes over time.
@@ -68,7 +72,7 @@ they are set to "Maintainers" by default.
 
 ## Restricting push and merge access to certain users **(STARTER)**
 
-> This feature was [introduced][ce-5081] in [GitLab Starter][ee] 8.11.
+> [Introduced][ce-5081] in [GitLab Starter][ee] 8.11.
 
 With GitLab Enterprise Edition you can restrict access to protected branches
 by choosing a role (Maintainers, Developers) as well as certain users. From the
@@ -174,11 +178,21 @@ for details about the pipelines security model.
 - Allow developers to merge into a protected branch without having push access [gitlab-org/gitlab-ce!4892][ce-4892]
 - Allow specifying protected branches using wildcards [gitlab-org/gitlab-ce!4665][ce-4665]
 
----
-
 [ce-4665]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4665 "Allow specifying protected branches using wildcards"
 [ce-4892]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4892 "Allow developers to merge into a protected branch without having push access"
 [ce-5081]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5081 "Allow creating protected branches that can't be pushed to"
 [ce-21393]: https://gitlab.com/gitlab-org/gitlab-ce/issues/21393
 [perm]: ../permissions.md
 [ee]: https://about.gitlab.com/pricing/
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/user/project/protected_tags.md b/doc/user/project/protected_tags.md
index 26bec323f02..687c4e1ea6f 100644
--- a/doc/user/project/protected_tags.md
+++ b/doc/user/project/protected_tags.md
@@ -1,3 +1,7 @@
+---
+type: reference, howto
+---
+
 # Protected Tags
 
 > [Introduced][ce-10356] in GitLab 9.1.
@@ -14,19 +18,19 @@ Protected tags will prevent anyone from updating or deleting the tag, as and wil
 
 To protect a tag, you need to have at least Maintainer permission level.
 
-1. Navigate to the project's Settings -> Repository page
+1. Navigate to the project's **Settings > Repository**:
 
     ![Repository Settings](img/project_repository_settings.png)
 
-1. From the **Tag** dropdown menu, select the tag you want to protect or type and click `Create wildcard`. In the screenshot below, we chose to protect all tags matching `v*`.
+1. From the **Tag** dropdown menu, select the tag you want to protect or type and click **Create wildcard**. In the screenshot below, we chose to protect all tags matching `v*`:
 
     ![Protected tags page](img/protected_tags_page.png)
 
-1. From the `Allowed to create` dropdown, select who will have permission to create matching tags and then click `Protect`.
+1. From the **Allowed to create** dropdown, select who will have permission to create matching tags and then click **Protect**:
 
     ![Allowed to create tags dropdown](img/protected_tags_permissions_dropdown.png)
 
-1. Once done, the protected tag will appear in the "Protected tags" list.
+1. Once done, the protected tag will appear in the **Protected tags** list:
 
     ![Protected tags list](img/protected_tags_list.png)
 
@@ -45,13 +49,23 @@ matching the wildcard. For example:
 Two different wildcards can potentially match the same tag. For example,
 `*-stable` and `production-*` would both match a `production-stable` tag.
 In that case, if _any_ of these protected tags have a setting like
-"Allowed to create", then `production-stable` will also inherit this setting.
+**Allowed to create**, then `production-stable` will also inherit this setting.
 
 If you click on a protected tag's name, you will be presented with a list of
 all matching tags:
 
 ![Protected tag matches](img/protected_tag_matches.png)
 
----
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
 
 [ce-10356]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10356 "Protected Tags"
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index f81669a41c9..40fba8fb111 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -1,4 +1,8 @@
-# GitLab quick actions
+---
+type: reference
+---
+
+# GitLab Quick Actions
 
 Quick actions are textual shortcuts for common actions on issues, epics, merge requests,
 and commits that are usually done by clicking buttons or dropdowns in GitLab's UI.
@@ -7,7 +11,7 @@ in comments of issues, epics, merge requests, and commits. Each command should b
 on a separate line in order to be properly detected and executed. Once executed,
 the commands are removed from the text body and not visible to anyone else.
 
-## Quick actions for issues and merge requests
+## Quick Actions for issues and merge requests
 
 The following quick actions are applicable to both issues and merge requests threads,
 discussions, and descriptions:
@@ -96,3 +100,15 @@ The following quick actions are applicable for epics threads and description:
 | `/remove_child_epic <&epic | group&epic | Epic URL>` | Removes child epic from epic ([introduced in GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-ee/issues/7330)) |
 | `/parent_epic <&epic |  group&epic | Epic URL>` | Sets parent epic to epic ([introduced in GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-ee/issues/10556)) |
 | `/remove_parent_epic` | Removes parent epic from epic ([introduced in GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-ee/issues/10556)) |
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->