Proof of concept linting outside docs dirdocs-include-more-files

Shows how much work is required to enable linting on docs
changes outside the /docs dir, if required in the future

14 files changed, 153 insertions, 154 deletions

diff --git a/.gitlab/ci/docs.gitlab-ci.yml b/.gitlab/ci/docs.gitlab-ci.yml
index 3f29adddf73..8aa33e8c763 100644
--- a/.gitlab/ci/docs.gitlab-ci.yml
+++ b/.gitlab/ci/docs.gitlab-ci.yml
@@ -74,7 +74,7 @@ docs lint:
   script:
     - scripts/lint-doc.sh
     # Lint Markdown
-    - markdownlint --config .markdownlint.json 'doc/**/*.md'
+    - markdownlint --config .markdownlint.json --ignore={'CHANGELOG.md','changelogs/archive.md'} '**/*.md'
     # Prepare docs for build
     - mv doc/ /tmp/gitlab-docs/content/$DOCS_GITLAB_REPO_SUFFIX
     - cd /tmp/gitlab-docs
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e4c954448a5..9a5d8a43d66 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,4 +1,4 @@
-## Developer Certificate of Origin + License
+# Developer Certificate of Origin + License
 
 By contributing to GitLab B.V., You accept and agree to the following terms and
 conditions for Your present and future Contributions submitted to GitLab B.V.
@@ -40,7 +40,7 @@ This [documentation](doc/development/contributing/index.md#closing-policy-for-is
 
 This [documentation](doc/development/contributing/index.md#helping-others) has been moved.
 
-## I want to contribute!
+## I want to contribute
 
 [View the new documentation](https://about.gitlab.com/community/contribute/) to find the latest information.
 
diff --git a/PROCESS.md b/PROCESS.md
index f0a82838f62..87df059241b 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -1,4 +1,4 @@
-## GitLab core team & GitLab Inc. contribution process
+# GitLab core team & GitLab Inc. contribution process
 
 ---
 
@@ -56,7 +56,7 @@ Below we describe the contributing process to GitLab for two reasons:
 Several people from the [GitLab team][team] are helping community members to get
 their contributions accepted by meeting our [Definition of done][done].
 
-What you can expect from them is described at https://about.gitlab.com/job-families/expert/merge-request-coach/.
+What you can expect from them is described at <https://about.gitlab.com/job-families/expert/merge-request-coach/>.
 
 ### Milestones on community contribution issues
 
@@ -111,16 +111,16 @@ deployed to GitLab.com prior to this date.
 
 These types of merge requests for the upcoming release need special consideration:
 
-* **Large features**: a large feature is one that is highlighted in the kick-off
+- **Large features**: a large feature is one that is highlighted in the kick-off
   and the release blogpost; typically this will have its own channel in Slack
   and a dedicated team with front-end, back-end, and UX.
-* **Small features**: any other feature request.
+- **Small features**: any other feature request.
 
 It is strongly recommended that **large features** be with a maintainer **by the
 1st**. This means that:
 
-* There is a merge request (even if it's WIP).
-* The person (or people, if it needs a frontend and backend maintainer) who will
+- There is a merge request (even if it's WIP).
+- The person (or people, if it needs a frontend and backend maintainer) who will
   ultimately be responsible for merging this have been pinged on the MR.
 
 It's OK if merge request isn't completely done, but this allows the maintainer
@@ -195,12 +195,12 @@ information, see
 Once the stable branch is frozen, the only MRs that can be cherry-picked into
 the stable branch are:
 
-* Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing bugs](#managing-bugs) section.
-* Fixes for security issues.
-* Fixes or improvements to automated QA scenarios.
-* [Documentation improvements](https://docs.gitlab.com/ee/development/documentation/workflow.html) for feature changes made in the same release, though initial docs for these features should have already been merged by the freeze, as required.
-* New or updated translations (as long as they do not touch application code).
-* Changes that are behind a feature flag and have the ~"feature flag" label.
+- Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing bugs](#managing-bugs) section.
+- Fixes for security issues.
+- Fixes or improvements to automated QA scenarios.
+- [Documentation improvements](https://docs.gitlab.com/ee/development/documentation/workflow.html) for feature changes made in the same release, though initial docs for these features should have already been merged by the freeze, as required.
+- New or updated translations (as long as they do not touch application code).
+- Changes that are behind a feature flag and have the ~"feature flag" label.
 
 During the feature freeze all merge requests that are meant to go into the
 upcoming release should have the correct milestone assigned _and_ the
@@ -256,15 +256,17 @@ Regressions should be considered high priority issues that should be solved as s
 ### Managing bugs
 
 **Prioritization:** We give higher priority to regressions on features that worked in the last recent monthly release and the current release candidates.
-The two scenarios below can [bypass the exception request in the release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md#after-the-7th), where the affected regression version matches the current monthly release version.
-* A regression which worked in the **Last monthly release**
-   * **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
-   * *Note:* When we say `the last recent monthly release`, this can refer to either the version currently running on GitLab.com, or the most recent version available in the package repositories.
-* A regression which worked in the **Current release candidates**
-   * **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
-   * *Note:* Because GitLab.com runs release candidates of new releases, a regression can be reported in a release before its 'official' release date on the 22nd of the month.
+The two scenarios below can [bypass the exception request in the release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md#after-the-7th), where the affected regression version matches the current monthly release version:
+
+- A regression which worked in the **Last monthly release**
+  - **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
+  - *Note:* When we say `the last recent monthly release`, this can refer to either the version currently running on GitLab.com, or the most recent version available in the package repositories.
+- A regression which worked in the **Current release candidates**
+  - **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
+  - *Note:* Because GitLab.com runs release candidates of new releases, a regression can be reported in a release before its 'official' release date on the 22nd of the month.
 
 When a bug is found:
+
 1. Create an issue describing the problem in the most detailed way possible.
 1. If possible, provide links to real examples and how to reproduce the problem.
 1. Label the issue properly, by respecting the [Partial triage level](https://about.gitlab.com/handbook/engineering/issue-triage/#partial-triage).
diff --git a/README.md b/README.md
index bfc55f28279..8eba0ce2c17 100644
--- a/README.md
+++ b/README.md
@@ -70,7 +70,9 @@ To work on GitLab itself, we recommend setting up your development environment w
 If you do not use the GitLab Development Kit you need to install and setup all the dependencies yourself, this is a lot of work and error prone.
 One small thing you also have to do when installing it yourself is to copy the example development unicorn configuration file:
 
-    cp config/unicorn.rb.example.development config/unicorn.rb
+```sh
+cp config/unicorn.rb.example.development config/unicorn.rb
+```
 
 Instructions on how to start GitLab and how to run the tests can be found in the [getting started section of the GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit#getting-started).
 
diff --git a/app/presenters/README.md b/app/presenters/README.md
index a4d592b54d6..5aa87b8ab11 100644
--- a/app/presenters/README.md
+++ b/app/presenters/README.md
@@ -24,7 +24,7 @@ Presenters should be used for:
 
 - Data and logic methods that can be pulled & combined into single methods from
   view. This can include loops extracted from views too. A good example is
-  https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7073/diffs.
+  <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7073/diffs>.
 - Data and logic methods that can be pulled from models.
 - Simple text output methods: it's ok if the method returns a string, but not a
   whole DOM element for which we'd need HAML, a view context, helpers etc.
@@ -42,7 +42,7 @@ Nonetheless, the main issue is that concerns don’t make the model object more
 cohesive. The code is just better organized. In other words, there’s no real
 change to the API of the model.
 
-– https://www.toptal.com/ruby-on-rails/decoupling-rails-components
+– <https://www.toptal.com/ruby-on-rails/decoupling-rails-components>
 
 ## Benefits
 
diff --git a/app/serializers/README.md b/app/serializers/README.md
index bb94745b0b5..ff22e7f7711 100644
--- a/app/serializers/README.md
+++ b/app/serializers/README.md
@@ -12,15 +12,15 @@ that is usually consumed by a frontend code.
 
 Using serializers, instead of `to_json` method, has several benefits:
 
-* it helps to prevent exposure of a sensitive data stored in the database
-* it makes it easier to test what should and should not be exposed
-* it makes it easier to reuse serialization entities that are building blocks
-* it makes it easier to move complexity from controllers to easily testable
+- it helps to prevent exposure of a sensitive data stored in the database
+- it makes it easier to test what should and should not be exposed
+- it makes it easier to reuse serialization entities that are building blocks
+- it makes it easier to move complexity from controllers to easily testable
   classes
-* it encourages hiding complexity behind intentions-revealing interfaces
-* it makes it easier to take care about serialization performance concerns
-* it makes it easier to reduce merge conflicts between CE -> EE
-* it makes it easier to benefit from domain driven development techniques
+- it encourages hiding complexity behind intentions-revealing interfaces
+- it makes it easier to take care about serialization performance concerns
+- it makes it easier to reduce merge conflicts between CE -> EE
+- it makes it easier to benefit from domain driven development techniques
 
 ## What is a serializer?
 
@@ -250,57 +250,57 @@ MyObjectSerializer.new.represent(object.present)
 
 1. Do not invoke a serializer from within a serialization entity.
 
-    If you need to use a serializer from within a serialization entity, it is
-    possible that you are missing a class for an important domain concept.
+   If you need to use a serializer from within a serialization entity, it is
+   possible that you are missing a class for an important domain concept.
 
-    Consider creating a new domain class and a corresponding serialization
-    entity for it.
+   Consider creating a new domain class and a corresponding serialization
+   entity for it.
 
 1. Use only one approach to switch behavior of the serializer.
 
-    It is possible to use a few approaches to switch a behavior of the
-    serializer. Most common are using a [Fluent Interface][fluent-interface]
-    and creating a separate `represent_something` methods.
+   It is possible to use a few approaches to switch a behavior of the
+   serializer. Most common are using a [Fluent Interface][fluent-interface]
+   and creating a separate `represent_something` methods.
 
-    Whatever you choose, it might be better to use only one approach at a time.
+   Whatever you choose, it might be better to use only one approach at a time.
 
 1. Do not forget about creating specs for serialization entities.
 
-    Writing tests for the serializer indeed does cover testing a behavior of
-    serialization entities that the serializer instantiates. However it might
-    be a good idea to write separate tests for entities as well, because these
-    are meant to be reused in different serializers, and a serializer can
-    change a behavior of a serialization entity.
+   Writing tests for the serializer indeed does cover testing a behavior of
+   serialization entities that the serializer instantiates. However it might
+   be a good idea to write separate tests for entities as well, because these
+   are meant to be reused in different serializers, and a serializer can
+   change a behavior of a serialization entity.
 
 1. Use `ActiveRecord::Relation` where possible
 
-    Using an `ActiveRecord::Relation` might help from the performance perspective.
+   Using an `ActiveRecord::Relation` might help from the performance perspective.
 
 1. Be diligent about passing an additional context from the controller.
 
-    Using `EntityRequest` and `RequestAwareEntity` is a workaround for the lack
-    of high-level mechanism. It is meant to be refactored, and current
-    implementation is error prone. Imagine the situation that one serialization
-    entity requires `request.user` attribute, but the second one wants
-    `request.current_user`. When it happens that these two entities are used in
-    the same serialization request, you might need to pass both parameters to
-    the serializer, which is obviously not a perfect situation.
+   Using `EntityRequest` and `RequestAwareEntity` is a workaround for the lack
+   of high-level mechanism. It is meant to be refactored, and current
+   implementation is error prone. Imagine the situation that one serialization
+   entity requires `request.user` attribute, but the second one wants
+   `request.current_user`. When it happens that these two entities are used in
+   the same serialization request, you might need to pass both parameters to
+   the serializer, which is obviously not a perfect situation.
 
-    When in doubt, pass only `current_user` and `project` if these are required.
+   When in doubt, pass only `current_user` and `project` if these are required.
 
 1. Keep performance concerns in mind
 
-    Using a serializer incorrectly can have significant impact on the
-    performance.
+   Using a serializer incorrectly can have significant impact on the
+   performance.
 
-    Because serializers are technically presenters, it is often necessary
-    to calculate, for example, paths to various controller-actions.
-    Since using URL helpers usually involve passing `project` and `namespace`
-    adding `includes(project: :namespace)` in the serializer, can help to avoid
-    N+1 queries.
+   Because serializers are technically presenters, it is often necessary
+   to calculate, for example, paths to various controller-actions.
+   Since using URL helpers usually involve passing `project` and `namespace`
+   adding `includes(project: :namespace)` in the serializer, can help to avoid
+   N+1 queries.
 
-    Also, try to avoid using `Enumerable#map` or other methods that will
-    execute a database query eagerly.
+   Also, try to avoid using `Enumerable#map` or other methods that will
+   execute a database query eagerly.
 
 1. Avoid passing `only` and `except` from the controller.
 1. Write tests checking for N+1 queries.
@@ -310,7 +310,7 @@ MyObjectSerializer.new.represent(object.present)
 
 ## Future
 
-* [Next iteration of serializers][issue-27569]
+- [Next iteration of serializers][issue-27569]
 
 [grape-project]: http://www.ruby-grape.org
 [grape-entity-project]: https://github.com/ruby-grape/grape-entity
diff --git a/config/README.md b/config/README.md
index 9226f71a374..444fdedcaec 100644
--- a/config/README.md
+++ b/config/README.md
@@ -21,7 +21,7 @@ This file is called `resque.yml` for historical reasons. We are **NOT**
 using Resque at the moment. It is used to specify Redis configuration
 values when a single database instance of Redis is desired.
 
-# Advanced Redis configuration files
+## Advanced Redis configuration files
 
 In more advanced configurations of Redis key-value storage, it is desirable
 to separate the keys by lifecycle and intended use to ease provisioning and
@@ -32,27 +32,29 @@ persistence policies, and other Redis customization) for connections
 to Redis single instances, Redis sentinel, and Redis clusters.
 
 If desired, the routing URL provided by these settings can be used with:
+
 1. Unix Socket
-    1. named socket for each Redis instance desired.
-    2. `database number` for each Redis instance desired.
-2. TCP Socket
-    1. `host name` or IP for each Redis instance desired
-    2. TCP port number for each Redis instance desired
-    3. `database number` for each Redis instance desired
-
-## Example URL attribute formats for GitLab Redis `.yml` configuration files
-* Unix Socket, default Redis database (0)
-    * `url: unix:/path/to/redis.sock`
-    * `url: unix:/path/to/redis.sock?db=`
-* Unix Socket, Redis database 44
-    * `url: unix:/path/to/redis.sock?db=44`
-    * `url: unix:/path/to/redis.sock?extra=foo&db=44`
-* TCP Socket for Redis on localhost, port 6379, database 33
-    * `url: redis://:mynewpassword@localhost:6379/33`
-* TCP Socket for Redis on remote host `myserver`, port 6379, database 33
-    * `url: redis://:mynewpassword@myserver:6379/33`
-
-## redis.cache.yml
+   1. named socket for each Redis instance desired.
+   1. `database number` for each Redis instance desired.
+1. TCP Socket
+   1. `host name` or IP for each Redis instance desired
+   1. TCP port number for each Redis instance desired
+   1. `database number` for each Redis instance desired
+
+### Example URL attribute formats for GitLab Redis `.yml` configuration files
+
+- Unix Socket, default Redis database (0)
+  - `url: unix:/path/to/redis.sock`
+  - `url: unix:/path/to/redis.sock?db=`
+- Unix Socket, Redis database 44
+  - `url: unix:/path/to/redis.sock?db=44`
+  - `url: unix:/path/to/redis.sock?extra=foo&db=44`
+- TCP Socket for Redis on localhost, port 6379, database 33
+  - `url: redis://:mynewpassword@localhost:6379/33`
+- TCP Socket for Redis on remote host `myserver`, port 6379, database 33
+  - `url: redis://:mynewpassword@myserver:6379/33`
+
+### redis.cache.yml
 
 If configured, `redis.cache.yml` overrides the
 `resque.yml` settings to configure the Redis database instance
@@ -64,26 +66,28 @@ an alternate location for configuration settings.
 
 The order of precedence for the URL used to connect to the Redis instance
 used for `cache` is:
+
 1. URL from a configuration file pointed to by the
-`GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
-2. URL from `redis.cache.yml`
-3. URL from a configuration file pointed to by the
-`GITLAB_REDIS_CONFIG_FILE` environment variable
-4. URL from `resque.yml`
-5. `redis://localhost:6380`
+   `GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
+1. URL from `redis.cache.yml`
+1. URL from a configuration file pointed to by the
+   `GITLAB_REDIS_CONFIG_FILE` environment variable
+1. URL from `resque.yml`
+1. `redis://localhost:6380`
 
 The order of precedence for all other configuration settings for `cache`
 are selected from only the first of the following files found (if a setting
 is not provided in an earlier file, the remainder of the files are not
 searched):
+
 1. the configuration file pointed to by the
-`GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
-2. the configuration file `redis.cache.yml`
-3. the configuration file pointed to by the
-`GITLAB_REDIS_CONFIG_FILE` environment variable
-4. the configuration file `resque.yml`
+   `GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
+1. the configuration file `redis.cache.yml`
+1. the configuration file pointed to by the
+   `GITLAB_REDIS_CONFIG_FILE` environment variable
+1. the configuration file `resque.yml`
 
-## redis.queues.yml
+### redis.queues.yml
 
 If configured, `redis.queues.yml` overrides the
 `resque.yml` settings to configure the Redis database instance
@@ -98,26 +102,28 @@ configuration settings.
 
 The order of precedence for the URL used to connect to the Redis instance
 used for `queues` is:
+
+1. URL from a configuration file pointed to by the
+   `GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
+1. URL from `redis.queues.yml`
 1. URL from a configuration file pointed to by the
-`GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
-2. URL from `redis.queues.yml`
-3. URL from a configuration file pointed to by the
 `GITLAB_REDIS_CONFIG_FILE` environment variable
-4. URL from `resque.yml`
-5. `redis://localhost:6381`
+1. URL from `resque.yml`
+1. `redis://localhost:6381`
 
 The order of precedence for all other configuration settings for `queues`
 are selected from only the first of the following files found (if a setting
 is not provided in an earlier file, the remainder of the files are not
 searched):
+
 1. the configuration file pointed to by the
-`GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
-2. the configuration file `redis.queues.yml`
-3. the configuration file pointed to by the
-`GITLAB_REDIS_CONFIG_FILE` environment variable
-4. the configuration file `resque.yml`
+   `GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
+1. the configuration file `redis.queues.yml`
+1. the configuration file pointed to by the
+   `GITLAB_REDIS_CONFIG_FILE` environment variable
+1. the configuration file `resque.yml`
 
-## redis.shared_state.yml
+### redis.shared_state.yml
 
 If configured, `redis.shared_state.yml` overrides the
 `resque.yml` settings to configure the Redis database instance
@@ -129,21 +135,23 @@ an alternate location for configuration settings.
 
 The order of precedence for the URL used to connect to the Redis instance
 used for `shared_state` is:
+
 1. URL from a configuration file pointed to by the
-`GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
-2. URL from `redis.shared_state.yml`
-3. URL from a configuration file pointed to by the
-`GITLAB_REDIS_CONFIG_FILE` environment variable
-4. URL from `resque.yml`
-5. `redis://localhost:6382`
+   `GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
+1. URL from `redis.shared_state.yml`
+1. URL from a configuration file pointed to by the
+   `GITLAB_REDIS_CONFIG_FILE` environment variable
+1. URL from `resque.yml`
+1. `redis://localhost:6382`
 
 The order of precedence for all other configuration settings for `shared_state`
 are selected from only the first of the following files found (if a setting
 is not provided in an earlier file, the remainder of the files are not
 searched):
+
 1. the configuration file pointed to by the
-`GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
-2. the configuration file `redis.shared_state.yml`
-3. the configuration file pointed to by the
-`GITLAB_REDIS_CONFIG_FILE` environment variable
-4. the configuration file `resque.yml`
+   `GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
+1. the configuration file `redis.shared_state.yml`
+1. the configuration file pointed to by the
+   `GITLAB_REDIS_CONFIG_FILE` environment variable
+1. the configuration file `resque.yml`
diff --git a/qa/README.md b/qa/README.md
index 332e5c8170f..7c1fff8f677 100644
--- a/qa/README.md
+++ b/qa/README.md
@@ -70,9 +70,9 @@ will need to [modify your GDK setup](https://gitlab.com/gitlab-org/gitlab-qa/blo
 ### Writing tests
 
 - [Writing tests from scratch tutorial](../doc/development/testing_guide/end_to_end/quick_start_guide.md)
-    - [Best practices](../doc/development/testing_guide/best_practices.md)
-    - [Using page objects](../doc/development/testing_guide/end_to_end/page_objects.md)
-    - [Guidelines](../doc/development/testing_guide/index.md)
+  - [Best practices](../doc/development/testing_guide/best_practices.md)
+  - [Using page objects](../doc/development/testing_guide/end_to_end/page_objects.md)
+  - [Guidelines](../doc/development/testing_guide/index.md)
 
 ### Running specific tests
 
@@ -134,7 +134,6 @@ canary fleet. To do this set `QA_COOKIES="gitlab_canary=true"`.
 
 To set multiple cookies, separate them with the `;` character, for example: `QA_COOKIES="cookie1=value;cookie2=value2"`
 
-
 ### Building a Docker image to test
 
 Once you have made changes to the CE/EE repositories, you may want to build a
diff --git a/spec/fixtures/blockquote_fence_after.md b/spec/fixtures/blockquote_fence_after.md
index 555905bf07e..2652a842c0e 100644
--- a/spec/fixtures/blockquote_fence_after.md
+++ b/spec/fixtures/blockquote_fence_after.md
@@ -18,13 +18,10 @@ Double `>>>` inside code block:
 
 Blockquote outside code block:
 
-
 > Quote
 
-
 Code block inside blockquote:
 
-
 > Quote
 >
 > ```
@@ -33,10 +30,8 @@ Code block inside blockquote:
 >
 > Quote
 
-
 Single `>>>` inside code block inside blockquote:
 
-
 > Quote
 >
 > ```
@@ -47,10 +42,8 @@ Single `>>>` inside code block inside blockquote:
 >
 > Quote
 
-
 Double `>>>` inside code block inside blockquote:
 
-
 > Quote
 >
 > ```
@@ -63,7 +56,6 @@ Double `>>>` inside code block inside blockquote:
 >
 > Quote
 
-
 Single `>>>` inside HTML:
 
 <pre>
@@ -84,13 +76,10 @@ Double `>>>` inside HTML:
 
 Blockquote outside HTML:
 
-
 > Quote
 
-
 HTML inside blockquote:
 
-
 > Quote
 >
 > <pre>
@@ -99,10 +88,8 @@ HTML inside blockquote:
 >
 > Quote
 
-
 Single `>>>` inside HTML inside blockquote:
 
-
 > Quote
 >
 > <pre>
@@ -113,10 +100,8 @@ Single `>>>` inside HTML inside blockquote:
 >
 > Quote
 
-
 Double `>>>` inside HTML inside blockquote:
 
-
 > Quote
 >
 > <pre>
@@ -128,4 +113,3 @@ Double `>>>` inside HTML inside blockquote:
 > </pre>
 >
 > Quote
-
diff --git a/spec/fixtures/encoding/Japanese.md b/spec/fixtures/encoding/Japanese.md
index dd469c9f232..b87c1861915 100644
--- a/spec/fixtures/encoding/Japanese.md
+++ b/spec/fixtures/encoding/Japanese.md
@@ -1,24 +1,26 @@
 +++
 date = "2017-05-21T13:05:07+09:00"
-title = "レイヤ"
 weight = 10
-
 +++
 
+# レイヤ
+
 ## このチュートリアルで扱う内容
+
 1. Redactedにおける2D開発でのレイヤの基本的な概要
-2. スクリーン上のスプライトの順序付け方法
+1. スクリーン上のスプライトの順序付け方法
 
 ### Redactedにおける2D開発でのレイヤの基本的な概要
+
 2Dにおいてはz軸が存在しないため、シーン内要素の描画順を制御するためには代替となる仕組みが必要です。
 Redactedでは**レイヤ**における**zIndex**属性を制御可能にすることで、この課題を解決しています。
 **デフォルトでは、zIndexは0となりオブジェクトはレイヤに追加された順番に描画されます。**
 
 レイヤにはいくつかの重要な特性があります。
 
-* レイヤにはレイヤ化されたオブジェクトのみを含めることができます。(**3Dモデルは絶対に追加しないでください**）
-* レイヤはレイヤ化されたオブジェクトです。（したがって、レイヤには他のレイヤを含めることができます)
-* レイヤ化されたオブジェクトは、最大で1つのレイヤに属すことができます。
+- レイヤにはレイヤ化されたオブジェクトのみを含めることができます。(**3Dモデルは絶対に追加しないでください**）
+- レイヤはレイヤ化されたオブジェクトです。（したがって、レイヤには他のレイヤを含めることができます)
+- レイヤ化されたオブジェクトは、最大で1つのレイヤに属すことができます。
 
 レイヤを直接初期化することはできませんが、その派生クラスは初期化することが可能です。**Scene2D**と**コンテナ**は、**レイヤ**から派生する2つの主なオブジェクトです。すべての初期化（createContainer、instantiate、...）はレイヤ上で行われます。つまり、2Dで初期化されるすべてのオブジェクトは、zIndexプロパティを持つレイヤ化されたオブジェクトです。
 
@@ -27,16 +29,18 @@ Redactedでは**レイヤ**における**zIndex**属性を制御可能にする�
 CSSとは異なり、zIndexはすべてのオブジェクトに対してグローバルではありません。zIndexプロパティは親レイヤに対してローカルです。詳細につきましては、コンテナチュートリアルで説明しています。 [TODO: Link]。
 
 ### スクリーン上のスプライトの順序付け方法
+
 これまで学んだことを生かして、画面にスプライトを表示して、zIndexの設定をしてみましょう！
 
-* まず、最初に (A,B,C)　スプライトを生成します。
-* スプライトAをシーンに追加します（zIndex = 0、標準色）
-* スプライトBをシーン2に追加すると、**スプライトAの上に**表示されます（zIndex = 0、赤色）
-* 最後にスプライトCをシーンに追加します（青色）が、スプライトのzIndexを-1に設定すると、スプライトはAとBの後側に表示されます。
+- まず、最初に (A,B,C)　スプライトを生成します。
+- スプライトAをシーンに追加します（zIndex = 0、標準色）
+- スプライトBをシーン2に追加すると、**スプライトAの上に**表示されます（zIndex = 0、赤色）
+- 最後にスプライトCをシーンに追加します（青色）が、スプライトのzIndexを-1に設定すると、スプライトはAとBの後側に表示されます。
 
 {{< code "static/tutorials/layers.html" >}}
 
 ### ソースコード全体
+
 ```js
 {{< snippet "static/tutorials/layers.html" >}}
 ```
diff --git a/spec/frontend/fixtures/static/README.md b/spec/frontend/fixtures/static/README.md
index 011601d0df8..f043fefca1d 100644
--- a/spec/frontend/fixtures/static/README.md
+++ b/spec/frontend/fixtures/static/README.md
@@ -1,3 +1,3 @@
-# Please do not add new files here!
+# Please do not add new files here
 
 Instead use a Ruby file in the fixtures root directory (`spec/frontend/fixtures/`).
diff --git a/spec/migrations/README.md b/spec/migrations/README.md
index 5df44dbc355..9746e55d4ff 100644
--- a/spec/migrations/README.md
+++ b/spec/migrations/README.md
@@ -91,7 +91,7 @@ Example: `describe SomeClass, :migration, schema: 20170608152748`.
 ### Example
 
 This spec tests the [`lib/gitlab/background_migration/archive_legacy_traces.rb`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.6.5/lib/gitlab/background_migration/archive_legacy_traces.rb)
-background migration. You can find the complete spec on 
+background migration. You can find the complete spec on
 [`spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.6.5/spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb)
 
 ```ruby
diff --git a/vendor/Dockerfile/CONTRIBUTING.md b/vendor/Dockerfile/CONTRIBUTING.md
index 3e98f2e7b5b..48b9f9c41cd 100644
--- a/vendor/Dockerfile/CONTRIBUTING.md
+++ b/vendor/Dockerfile/CONTRIBUTING.md
@@ -1,4 +1,4 @@
-## Developer Certificate of Origin + License
+# Developer Certificate of Origin + License
 
 By contributing to GitLab B.V., You accept and agree to the following terms and
 conditions for Your present and future Contributions submitted to GitLab B.V.
diff --git a/vendor/gitignore/Global/README.md b/vendor/gitignore/Global/README.md
index 06b6649bd9a..2b93174b200 100644
--- a/vendor/gitignore/Global/README.md
+++ b/vendor/gitignore/Global/README.md
@@ -1,4 +1,4 @@
-## Globally Useful gitignores
+# Globally Useful gitignores
 
 This directory contains globally useful gitignores,
 e.g. OS-specific and editor specific.