Clean up headers in markdown

Some markdown headers needed tweaking to adhere
to standards, including blank lines above and below,
only one space after hash, first header should be
h1, and only one h1 per doc

7 files changed, 22 insertions, 13 deletions

diff --git a/doc/development/contributing/community_roles.md b/doc/development/contributing/community_roles.md
index 3296cb173d7..7d2d1b77a0e 100644
--- a/doc/development/contributing/community_roles.md
+++ b/doc/development/contributing/community_roles.md
@@ -1,4 +1,4 @@
-### Community members & roles
+# Community members & roles
 
 GitLab community members and their privileges/responsibilities.
 
diff --git a/doc/development/fe_guide/axios.md b/doc/development/fe_guide/axios.md
index 0d9397c3bd5..09b4a3c3d96 100644
--- a/doc/development/fe_guide/axios.md
+++ b/doc/development/fe_guide/axios.md
@@ -1,15 +1,18 @@
 # Axios
+
 We use [axios][axios] to communicate with the server in Vue applications and most new code.
 
 In order to guarantee all defaults are set you *should not use `axios` directly*, you should import `axios` from `axios_utils`.
 
 ## CSRF token
+
 All our request require a CSRF token.
 To guarantee this token is set, we are importing [axios][axios], setting the token, and exporting `axios` .
 
 This exported module should be used instead of directly using `axios` to ensure the token is set.
 
 ## Usage
+
 ```javascript
   import axios from './lib/utils/axios_utils';
 
diff --git a/doc/development/fe_guide/style_guide_scss.md b/doc/development/fe_guide/style_guide_scss.md
index f895cfd36ac..95c4a094c04 100644
--- a/doc/development/fe_guide/style_guide_scss.md
+++ b/doc/development/fe_guide/style_guide_scss.md
@@ -212,6 +212,7 @@ selectors are intended for use only with JavaScript to allow for removal or
 renaming without breaking styling.
 
 ### IDs
+
 Don't use ID selectors in CSS.
 
 ```scss
diff --git a/doc/development/module_with_instance_variables.md b/doc/development/module_with_instance_variables.md
index 7bdfa04fc57..443eee0b62c 100644
--- a/doc/development/module_with_instance_variables.md
+++ b/doc/development/module_with_instance_variables.md
@@ -1,6 +1,6 @@
-## Modules with instance variables could be considered harmful
+# Modules with instance variables could be considered harmful
 
-### Background
+## Background
 
 Rails somehow encourages people using modules and instance variables
 everywhere. For example, using instance variables in the controllers,
@@ -9,7 +9,7 @@ helpers, and views. They're also encouraging the use of
 saving everything in a giant, single object, and people could access
 everything in that one giant object.
 
-### The problems
+## The problems
 
 Of course this is convenient to develop, because we just have everything
 within reach. However this has a number of downsides when that chosen object
@@ -24,7 +24,7 @@ manipulated from 3 different modules. It's hard to track when those variables
 start giving us troubles. We don't know which module would suddenly change
 one of the variables. Everything could touch anything.
 
-### Similar concerns
+## Similar concerns
 
 People are saying multiple inheritance is bad. Mixing multiple modules with
 multiple instance variables scattering everywhere suffer from the same issue.
@@ -40,7 +40,7 @@ Note that `included` doesn't solve the whole issue. They define the
 dependencies, but they still allow each modules to talk implicitly via the
 instance variables in the final giant object, and that's where the problem is.
 
-### Solutions
+## Solutions
 
 We should split the giant object into multiple objects, and they communicate
 with each other with the API, i.e. public methods. In short, composition over
@@ -53,7 +53,7 @@ With clearly defined API, this would make things less coupled and much easier
 to debug and track, and much more extensible for other objects to use, because
 they communicate in a clear way, rather than implicit dependencies.
 
-### Acceptable use
+## Acceptable use
 
 However, it's not always bad to use instance variables in a module,
 as long as it's contained in the same module; that is, no other modules or
@@ -74,7 +74,7 @@ Unfortunately it's not easy to code more complex rules into the cop, so
 we rely on people's best judgement. If we could find another good pattern
 we could easily add to the cop, we should do it.
 
-### How to rewrite and avoid disabling this cop
+## How to rewrite and avoid disabling this cop
 
 Even if we could just disable the cop, we should avoid doing so. Some code
 could be easily rewritten in simple form. Consider this acceptable method:
@@ -181,7 +181,7 @@ rather than whatever includes the module, and those modules which were also
 included, making it much easier to track down any issues,
 and reducing the chance of having name conflicts.
 
-### How to disable this cop
+## How to disable this cop
 
 Put the disabling comment right after your code in the same line:
 
@@ -210,14 +210,14 @@ end
 Note that you need to enable it at some point, otherwise everything below
 won't be checked.
 
-### Things we might need to ignore right now
+## Things we might need to ignore right now
 
 Because of the way Rails helpers and mailers work, we might not be able to
 avoid the use of instance variables there. For those cases, we could ignore
 them at the moment. At least we're not going to share those modules with
 other random objects, so they're still somewhat isolated.
 
-### Instance variables in views
+## Instance variables in views
 
 They're bad because we can't easily tell who's using the instance variables
 (from controller's point of view) and where we set them up (from partials'
diff --git a/doc/development/new_fe_guide/development/accessibility.md b/doc/development/new_fe_guide/development/accessibility.md
index 81a29170129..ae5c4c6a6cc 100644
--- a/doc/development/new_fe_guide/development/accessibility.md
+++ b/doc/development/new_fe_guide/development/accessibility.md
@@ -1,17 +1,21 @@
 # Accessiblity
+
 Using semantic HTML plays a key role when it comes to accessibility.
 
 ## Accessible Rich Internet Applications - ARIA
+
 WAI-ARIA, the Accessible Rich Internet Applications specification, defines a way to make Web content and Web applications more accessible to people with disabilities.
 
 > Note: It is [recommended][using-aria] to use semantic elements as the primary method to achieve accessibility rather than adding aria attributes. Adding aria attributes should be seen as a secondary method for creating accessible elements.
 
 ### Role
+
 The `role` attribute describes the role the element plays in the context of the document.
 
 Check the list of WAI-ARIA roles [here][roles]
 
 ## Icons
+
 When using icons or images that aren't absolutely needed to understand the context, we should use `aria-hidden="true"`.
 
 On the other hand, if an icon is crucial to understand the context we should do one of the following:
@@ -20,6 +24,7 @@ On the other hand, if an icon is crucial to understand the context we should do
 1. Use `aria-labelledby` to point to an element that contains the explanation for that icon
 
 ## Form inputs
+
 In forms we should use the `for` attribute in the label statement:
 
 ```
diff --git a/doc/development/new_fe_guide/style/index.md b/doc/development/new_fe_guide/style/index.md
index 335d9e66240..f073dc56f1f 100644
--- a/doc/development/new_fe_guide/style/index.md
+++ b/doc/development/new_fe_guide/style/index.md
@@ -8,7 +8,7 @@
 
 ## [Vue style guide](vue.md)
 
-# Tooling
+## Tooling
 
 ## [Prettier](prettier.md)
 
diff --git a/doc/development/verifying_database_capabilities.md b/doc/development/verifying_database_capabilities.md
index 661ab9cef1a..ccec6f7d719 100644
--- a/doc/development/verifying_database_capabilities.md
+++ b/doc/development/verifying_database_capabilities.md
@@ -25,7 +25,7 @@ else
 end
 ```
 
-# Read-only database
+## Read-only database
 
 The database can be used in read-only mode. In this case we have to
 make sure all GET requests don't attempt any write operations to the