Port from CE:

- Refactor and restructure pipelines landing page.
- Also has other minor improvements.

doc/api/pipeline_schedules.md

-# Pipeline schedules
+# Pipeline schedules API
 
 You can read more about [pipeline schedules](../user/project/pipelines/schedules.md).
 
@@ -280,7 +280,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gi
 
 ## Pipeline schedule variable
 
-> [Introduced][ce-34518] in GitLab 10.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/34518) in GitLab 10.0.
 
 ## Create a new pipeline schedule variable
 
@@ -358,5 +358,3 @@ curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gi
     "value": "updated value"
 }
 ```
-
-[ce-34518]: https://gitlab.com/gitlab-org/gitlab-ce/issues/34518
\ No newline at end of file

doc/ci/README.md

@@ -45,7 +45,7 @@ into more features:
 
 | Topic                                                                                                                | Description                                                                                                                  |
 |:---------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------|
-| [Introduction to pipelines and jobs](pipelines.md)                                                                   | Provides an overview of GitLab CI/CD and jobs.                                                                               |
+| [Creating and using CI/CD pipelines](pipelines.md)                                                                   | Understand, visualize, create, and use CI/CD pipelines.                                                                      |
 | [CI/CD Variables](variables/README.md)                                                                               | How environment variables can be configured and made available in pipelines.                                                 |
 | [Where variables can be used](variables/where_variables_can_be_used.md)                                              | A deeper look into where and how CI/CD variables can be used.                                                                |
 | [User](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions | Learn about the access levels a user can have for performing certain CI actions.                                             |

doc/ci/merge_request_pipelines/index.md

@@ -9,13 +9,18 @@ For example, unit tests, lint checks, and [Review Apps](../review_apps/index.md)
 are often used in this cycle.
 
 With pipelines for merge requests, you can design a specific pipeline structure
-for merge requests. All you need to do is just adding `only: [merge_requests]` to
-the jobs that you want it to run for only merge requests.
-Every time, when developers create or update merge requests, a pipeline runs on
+for merge requests.
+
+## Configuring pipelines for merge requests
+
+To configure pipelines for merge request, add the `only: merge_requests` parameter to
+the jobs that you want it to run only for merge requests.
+
+Then, when developers create or update merge requests, a pipeline runs on
 their new commits at every push to GitLab.
 
 NOTE: **Note**:
-If you use both this feature and [Merge When Pipeline Succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
+If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
 pipelines for merge requests take precedence over the other regular pipelines.
 
 For example, consider the following [`.gitlab-ci.yml`](../yaml/README.md):
@@ -40,15 +45,17 @@ deploy:
   script: ./deploy
 ```
 
-After the merge request is updated with new commits, GitLab detects that changes
-have occurred and creates a new pipeline for the merge request.
-The pipeline fetches the latest code from the source branch and run tests against it.
+After the merge request is updated with new commits:
+
+- GitLab detects that changes have occurred and creates a new pipeline for the merge request.
+- The pipeline fetches the latest code from the source branch and run tests against it.
+
 In the above example, the pipeline contains only `build` and `test` jobs.
-Since the `deploy` job doesn't have the `only: [merge_requests]` rule,
+Since the `deploy` job doesn't have the `only: merge_requests` rule,
 deployment jobs will not happen in the merge request.
 
-Pipelines tagged as **merge request** indicate that they were triggered
-when a merge request was created or updated.
+Pipelines tagged with **merge request** badge indicate that they were triggered
+when a merge request was created or updated. For example:
 
 ![Merge request page](img/merge_request.png)
 
@@ -62,9 +69,14 @@ The behavior of the `only: merge_requests` rule is such that _only_ jobs with
 that rule are run in the context of a merge request; no other jobs will be run.
 
 However, you may want to reverse this behaviour, having all of your jobs to run _except_
-for one or two. Consider the following pipeline, with jobs `A`, `B`, and `C`. If you want
-all pipelines to always run `A` and `B`, but only want `C` to run for a merge request,
-you can configure your `.gitlab-ci.yml` file as follows:
+for one or two.
+
+Consider the following pipeline, with jobs `A`, `B`, and `C`. Imagine you want:
+
+- All pipelines to always run `A` and `B`
+- Only want `C` to run for a merge request,
+
+To achieve this, you can configure your `.gitlab-ci.yml` file as follows:
 
 ``` yaml
 .only-default: &only-default
@@ -90,9 +102,11 @@ C:
     - merge_requests
 ```
 
-Since `A` and `B` are getting the `only:` rule to execute in all cases, they will
-always run. `C` specifies that it should only run for merge requests, so for any
-pipeline except a merge request pipeline, it will not run.
+Because:
+
+- `A` and `B` are getting the `only:` rule to execute in all cases, they will always run.
+- `C` specifies that it should only run for merge requests, it will not run for any pipeline
+  except a merge request pipeline.
 
 As you can see, this will help you avoid a lot of boilerplate where you'd need
 to add that `only:` rule to all of your jobs in order to make them always run. You

doc/user/project/merge_requests/merge_when_pipeline_succeeds.md

-# Merge When Pipeline Succeeds
+# Merge when pipeline succeeds
 
 When reviewing a merge request that looks ready to merge but still has one or
 more CI jobs running, you can set it to be merged automatically when the