Merge branch 'docs-20200122-spelling-user-section' into 'master'

Correct spelling in the user section

See merge request gitlab-org/gitlab!23557

doc/user/project/clusters/serverless/aws.md

@@ -78,7 +78,7 @@ service: gitlab-example
 provider:
   name: aws
   runtime: nodejs10.x
-  
+
 functions:
   hello:
     handler: src/handler.hello
@@ -222,7 +222,7 @@ From there, you can reference them in your functions as well.
 Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
 
 NOTE: **Note:**
-Anyone with access to the AWS environemnt may be able to see the values of those
+Anyone with access to the AWS environment may be able to see the values of those
 variables persisted in the lambda definition.
 
 ### Setting up CORS

doc/user/project/integrations/prometheus_library/cloudwatch.md

@@ -12,9 +12,9 @@ The [Prometheus service](../prometheus.md) must be enabled.
 
 | Name | Query |
 | ---- | ----- |
-| Throughput (req/sec) | sum(aws_elb_request_count_sum{%{environment_filter}}) / 60 |
-| Latency (ms) | avg(aws_elb_latency_average{%{environment_filter}}) * 1000 |
-| HTTP Error Rate (%) | sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}}) |
+| Throughput (req/sec) | `sum(aws_elb_request_count_sum{%{environment_filter}}) / 60` |
+| Latency (ms) | `avg(aws_elb_latency_average{%{environment_filter}}) * 1000` |
+| HTTP Error Rate (%) | `sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}})` |
 
 ## Configuring Prometheus to monitor for Cloudwatch metrics
 

doc/user/project/issues/csv_export.md

@@ -62,8 +62,8 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
 | Confidential | `Yes` or `No` |
 | Locked | `Yes` or `No` |
 | Due Date | Formated as `YYYY-MM-DD` |
-| Created At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
-| Updated At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
+| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
+| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
 | Milestone | Title of the issue milestone |
 | Weight | Issue weight |
 | Labels | Title of any labels joined with a `,` |

doc/user/project/merge_requests/creating_merge_requests.md

@@ -17,7 +17,7 @@ or through the GitLab UI.
 
 This document describes the several ways to create a merge request.
 
-When you start a new merge request, regarless of the method,
+When you start a new merge request, regardless of the method,
 you'll be taken to the [**New Merge Request** page](#new-merge-request-page)
 to fill it with information about the merge request.
 
@@ -29,9 +29,9 @@ button and start a merge request from there.
 
 On the **New Merge Request** page, start by filling in the title
 and description for the merge request. If there are are already
-commits on the branch, the title will be pre-filled with the first
+commits on the branch, the title will be prefilled with the first
 line of the first commit message, and the description will be
-pre-filled with any additional lines in the commit message.
+prefilled with any additional lines in the commit message.
 The title is the only field that is mandatory in all cases.
 
 From there, you can fill it with information (title, description,

doc/user/project/merge_requests/merge_when_pipeline_succeeds.md

@@ -63,7 +63,7 @@ merge request from the UI, until you make all relevant jobs pass.
 
 When this setting is enabled, a merge request is prevented from being merged if there is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/README.md#onlyexcept-advanced) rules are used and they don't generate any pipelines.
 
-Users that expect to be able to merge a merge request in this scenario should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/issues/54226) and that it's succesful.
+Users that expect to be able to merge a merge request in this scenario should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/issues/54226) and that it's successful.
 
 For example, to that on merge requests there is always a passing job even though `only/except` rules may not generate any other jobs:
 

doc/user/project/repository/forking_workflow.md

@@ -38,7 +38,7 @@ repository. There, you will have full [Owner](../../permissions.md)
 access, so you can set it up as you please.
 
 CAUTION: **CAUTION:**
-From GitLab 12.6 onwards, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
+From GitLab 12.6 onward, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
 in any way, the fork relationship with all its forks will be removed.
 
 CAUTION: **Caution:**

doc/user/project/web_ide/index.md

@@ -49,7 +49,7 @@ After making your changes, click the **Commit** button in the bottom left to
 review the list of changed files. If you're using GitLab 12.6 or older versions,
 click on each file to review the changes and tick the item to stage a file.
 
-From [GitLab 12.7 onwards](https://gitlab.com/gitlab-org/gitlab/issues/33441),
+From [GitLab 12.7 onward](https://gitlab.com/gitlab-org/gitlab/issues/33441),
 all your files will be automatically staged. You still have the option to unstage
 changes in case you want to submit them in multiple smaller commits. To unstage
 a change, simply click the **Unstage** button when a staged file is open, or click