Fix markdown in various docs

Clean up issues that may cause the docs-lint
test to fail, such as trailing whitespace, no
EOF newline, blockquotes, etc

10 files changed, 7 insertions, 14 deletions

diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 3637a08c3cd..887f17b05b8 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -65,7 +65,7 @@ Sign up for the mailing list, answer GitLab questions on StackOverflow or
 respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with
 the remaining issues on the GitHub issue tracker.
 
-## I want to contribute!
+## I want to contribute
 
 If you want to contribute to GitLab,
 [issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors)
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index c1e3eb9680b..bfcda1dd7fc 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -783,8 +783,6 @@ For multiple paragraphs, use the symbol `>` before every line:
 >
 > - This is a list item
 > - Second item in the list
->
-> ### This is an `h3`
 ```
 
 Which renders to:
@@ -795,9 +793,6 @@ Which renders to:
 >
 > - This is a list item
 > - Second item in the list
->
-> ### This is an `h3`
->{:.no_toc}
 
 ## Terms
 
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index 676bce32998..3a8ea04407f 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -81,7 +81,7 @@ bundle and included on the page.
 > can find this out by inspecting `document.body.dataset.page` within your
 > browser's developer console while on any page within gitlab.
 
-#### Important Considerations:
+#### Important Considerations
 
 - **Keep Entry Points Lite:**
   Page-specific javascript entry points should be as lite as possible.  These
diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md
index 62be3786549..15b1af1aa8f 100644
--- a/doc/development/i18n/translation.md
+++ b/doc/development/i18n/translation.md
@@ -92,4 +92,3 @@ To propose additions to the glossary please
 In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
 So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
 When space is missing, the male gender should be used alone.
-
diff --git a/doc/development/new_fe_guide/dependencies.md b/doc/development/new_fe_guide/dependencies.md
index 8a6930acd37..161ffb1fb57 100644
--- a/doc/development/new_fe_guide/dependencies.md
+++ b/doc/development/new_fe_guide/dependencies.md
@@ -1,6 +1,6 @@
 # Dependencies
 
-## Adding Dependencies.
+## Adding Dependencies
 
 GitLab uses `yarn` to manage dependencies. These dependencies are defined in
 two groups within `package.json`, `dependencies` and `devDependencies`. For
diff --git a/doc/development/new_fe_guide/development/testing.md b/doc/development/new_fe_guide/development/testing.md
index e0d413b748b..b990425ca3c 100644
--- a/doc/development/new_fe_guide/development/testing.md
+++ b/doc/development/new_fe_guide/development/testing.md
@@ -3,4 +3,3 @@ redirect_to: '../../testing_guide/frontend_testing.md'
 ---
 
 This document was moved to [another location](../../testing_guide/frontend_testing.md).
-
diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md
index e1df8be8b6f..d52d6db38b9 100644
--- a/doc/development/testing_guide/end_to_end/quick_start_guide.md
+++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md
@@ -10,7 +10,7 @@ It's important to understand that end-to-end tests of isolated features, such as
 
 If you don't exactly understand what we mean by **not everything needs to happen through the GUI,** please make sure you've read the [best practices](best_practices.md) before moving on.
 
-## This document covers the following items:
+## This document covers the following items
 
 - [0.](#0-are-end-to-end-tests-needed) Identifying if end-to-end tests are really needed
 - [1.](#1-identifying-the-devops-stage) Identifying the [DevOps stage](https://about.gitlab.com/stages-devops-lifecycle/) of the feature that you are going to cover with end-to-end tests
diff --git a/doc/development/testing_guide/end_to_end/style_guide.md b/doc/development/testing_guide/end_to_end/style_guide.md
index 97560e616a1..54ed3f34c89 100644
--- a/doc/development/testing_guide/end_to_end/style_guide.md
+++ b/doc/development/testing_guide/end_to_end/style_guide.md
@@ -141,4 +141,4 @@ Resource::MergeRequest.fabricate! do |merge_request_page|
 end
 ```
 
-> Besides the advantage of having a standard in place, by following this standard we also write shorter lines of code.
\ No newline at end of file
+> Besides the advantage of having a standard in place, by following this standard we also write shorter lines of code.
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 11449712a04..28a60660995 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -132,7 +132,7 @@ to prevent other pods from being scheduled on this node pool.
 This is to ensure Tiller isn't affected by "noisy" neighbors that could put
 their node under pressure.
 
-## How to:
+## How to
 
 ### Log into my Review App
 
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 0090c84cbf0..1aee306f492 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -126,7 +126,7 @@ possible).
 | ---------- | -------------- | ----- |
 | `spec/features/` | [Capybara] + [RSpec] | If your test has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. |
 
-### Consider **not** writing a system test!
+### Consider **not** writing a system test
 
 If we're confident that the low-level components work well (and we should be if
 we have enough Unit & Integration tests), we shouldn't need to duplicate their