Remove extra whitespaces in docs

Removes all the extra whitespaces at end of lines,
inside tags, and removes extra newlines

7 files changed, 36 insertions, 37 deletions

diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 4fc38a460f8..0866d3baeeb 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -53,7 +53,7 @@ allowed.
 
 ### Exclude params from parent namespaces!
 
-> By default `declared(params) `includes parameters that were defined in all
+> By default `declared(params)`includes parameters that were defined in all
 parent namespaces.
 
 – <https://github.com/ruby-grape/grape#include-parent-namespaces>
diff --git a/doc/development/code_comments.md b/doc/development/code_comments.md
index 36962eb46d4..827a610efa2 100644
--- a/doc/development/code_comments.md
+++ b/doc/development/code_comments.md
@@ -1,11 +1,11 @@
 # Code comments
 
-Whenever you add comment to the code that is expected to be addressed at any time 
-in future, please create a technical debt issue for it. Then put a link to it 
+Whenever you add comment to the code that is expected to be addressed at any time
+in future, please create a technical debt issue for it. Then put a link to it
 to the code comment you've created. This will allow other developers to quickly
 check if a comment is still relevant and what needs to be done to address it.
 
-Examples: 
+Examples:
 
 ```rb
 # Deprecated scope until code_owner column has been migrated to rule_type.
diff --git a/doc/development/emails.md b/doc/development/emails.md
index 8baf343b133..1fd4139c91e 100644
--- a/doc/development/emails.md
+++ b/doc/development/emails.md
@@ -76,7 +76,7 @@ See the [Rails guides] for more info.
 
 ## Email namespace
 
-As of GitLab 11.7, we support a new format for email handler addresses.  This was done to 
+As of GitLab 11.7, we support a new format for email handler addresses.  This was done to
 support catch-all mailboxes.
 
 If you need to implement a feature which requires a new email handler, follow these rules
diff --git a/doc/development/licensed_feature_availability.md b/doc/development/licensed_feature_availability.md
index 7d0a6f6acda..80ec7b8c0cf 100644
--- a/doc/development/licensed_feature_availability.md
+++ b/doc/development/licensed_feature_availability.md
@@ -1,18 +1,18 @@
 # Licensed feature availability **(STARTER)**
 
-As of GitLab 9.4, we've been supporting a simplified version of licensed 
-feature availability checks via `ee/app/models/license.rb`, both for 
+As of GitLab 9.4, we've been supporting a simplified version of licensed
+feature availability checks via `ee/app/models/license.rb`, both for
 on-premise or GitLab.com plans and features.
 
 ## Restricting features scoped by namespaces or projects
 
 GitLab.com plans are persisted on user groups and namespaces, therefore, if you're adding a
-feature such as [Related issues](../user/project/issues/related_issues.md) or 
-[Service desk](../user/project/service_desk.md), 
+feature such as [Related issues](../user/project/issues/related_issues.md) or
+[Service desk](../user/project/service_desk.md),
 it should be restricted on namespace scope.
 
-1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in 
-  `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com 
+1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in
+  `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com
   features maps to on-premise _EES_, _Silver_ to _EEP_ and _Gold_ to _EEU_.
 2. Check using:
 
@@ -22,12 +22,12 @@ project.feature_available?(:feature_symbol)
 
 ## Restricting global features (instance)
 
-However, for features such as [Geo](../administration/geo/replication/index.md) and 
-[Load balancing](../administration/database_load_balancing.md), which cannot be restricted 
-to only a subset of projects or namespaces, the check will be made directly in 
+However, for features such as [Geo](../administration/geo/replication/index.md) and
+[Load balancing](../administration/database_load_balancing.md), which cannot be restricted
+to only a subset of projects or namespaces, the check will be made directly in
 the instance license.
 
-1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in 
+1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in
   `ee/app/models/license.rb`.
 2. Add the same feature symbol to `GLOBAL_FEATURES`
 3. Check using:
diff --git a/doc/development/newlines_styleguide.md b/doc/development/newlines_styleguide.md
index 5f7210020b6..a13adc2f13e 100644
--- a/doc/development/newlines_styleguide.md
+++ b/doc/development/newlines_styleguide.md
@@ -11,7 +11,7 @@ def method
 
   issue.save
 
-  render json: issue 
+  render json: issue
 end
 ```
 
@@ -21,7 +21,7 @@ def method
   issue = Issue.new
   issue.save
 
-  render json: issue 
+  render json: issue
 end
 ```
 
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 418efd9eef9..08aa0b08525 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -5,11 +5,11 @@ This document will guide you through adding another [package management system](
 See already supported package types in [Packages documentation](../administration/packages.md)
 
 Since GitLab packages' UI is pretty generic, it is possible to add new
-package system support by solely backend changes. This guide is superficial and does 
-not cover the way the code should be written. However, you can find a good example 
-by looking at existing merge requests with Maven and NPM support: 
+package system support by solely backend changes. This guide is superficial and does
+not cover the way the code should be written. However, you can find a good example
+by looking at existing merge requests with Maven and NPM support:
 
-- [NPM registry support](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8673). 
+- [NPM registry support](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8673).
 - [Maven repository](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6607).
 - [Instance level endpoint for Maven repository](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8757)
 
@@ -17,44 +17,44 @@ by looking at existing merge requests with Maven and NPM support:
 
 The existing database model requires the following:
 
-- Every package belongs to a project. 
+- Every package belongs to a project.
 - Every package file belongs to a package.
 - A package can have one or more package files.
 - The package model is based on storing information about the package and its version.
 
 ## API endpoints
 
-Package systems work with GitLab via API. For example `ee/lib/api/npm_packages.rb` 
-implements API endpoints to work with NPM clients. So, the first thing to do is to 
-add a new `ee/lib/api/your_name_packages.rb` file with API endpoints that are 
-necessary to make the package system client to work. Usually that means having 
-endpoints like: 
+Package systems work with GitLab via API. For example `ee/lib/api/npm_packages.rb`
+implements API endpoints to work with NPM clients. So, the first thing to do is to
+add a new `ee/lib/api/your_name_packages.rb` file with API endpoints that are
+necessary to make the package system client to work. Usually that means having
+endpoints like:
 
 - GET package information.
 - GET package file content.
 - PUT upload package.
 
 Since the packages belong to a project, it's expected to have project-level endpoint
-for uploading and downloading them. For example: 
+for uploading and downloading them. For example:
 
 ```
 GET https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/
 PUT https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/
 ```
 
-Group-level and instance-level endpoints are good to have but are optional. 
+Group-level and instance-level endpoints are good to have but are optional.
 
 NOTE: **Note:**
-To avoid name conflict for instance-level endpoints we use 
+To avoid name conflict for instance-level endpoints we use
 [the package naming convention](../user/project/packages/npm_registry.md#package-naming-convention)
 
 ## Configuration
 
-GitLab has a `packages` section in its configuration file (`gitlab.rb`). 
-It applies to all package systems supported by GitLab. Usually you don't need 
-to add anything there. 
+GitLab has a `packages` section in its configuration file (`gitlab.rb`).
+It applies to all package systems supported by GitLab. Usually you don't need
+to add anything there.
 
-Packages can be configured to use object storage, therefore your code must support it. 
+Packages can be configured to use object storage, therefore your code must support it.
 
 ## Database
 
@@ -63,6 +63,6 @@ Every time you upload a new package, you can either create a new record of `Pack
 or add files to existing record. `PackageFile` should be able to store all file-related
 information like the file `name`, `side`, `sha1`, etc.
 
-If there is specific data necessary to be stored for only one package system support, 
-consider creating a separate metadata model. See `packages_maven_metadata` table 
+If there is specific data necessary to be stored for only one package system support,
+consider creating a separate metadata model. See `packages_maven_metadata` table
 and `Packages::MavenMetadatum` model as example for package specific data.
diff --git a/doc/development/understanding_explain_plans.md b/doc/development/understanding_explain_plans.md
index bfbb7be70e3..11aafd7b639 100644
--- a/doc/development/understanding_explain_plans.md
+++ b/doc/development/understanding_explain_plans.md
@@ -654,7 +654,6 @@ and related tools such as:
 - <https://explain.depesz.com/>
 - <http://tatiyants.com/postgres-query-plan-visualization/>
 
-
 ## Producing query plans
 
 There are a few ways to get the output of a query plan. Of course you