Fix plurality and capitalization mismatches in docs

- Two references to `pipeline` in
  doc/development/testing_guide/end_to_end/index.md should have been
  `pipelines`

When fixing those, I notice the following:

- "Developer access" was referenced as "developer access", and it
  appears that we mostly capitalize Developer in this case

I searched the codebase for "developer access" and found a few other
occurrences:

- doc/development/documentation/workflow.md
- doc/user/project/new_ci_build_permissions_model.md
- doc/user/project/repository/repository_mirroring.md

While in those files I saw a couple of instances of `user` that should
be plural and also incorrect capitalization of "reporter access"

doc/api/group_milestones.md

@@ -98,7 +98,7 @@ Parameters:
 
 ## Delete group milestone
 
-Only for user with developer access to the group.
+Only for users with Developer access to the group.
 
 ```
 DELETE /groups/:id/milestones/:milestone_id

doc/api/milestones.md

@@ -96,7 +96,7 @@ Parameters:
 
 ## Delete project milestone
 
-Only for user with developer access to the project.
+Only for users with Developer access to the project.
 
 ```
 DELETE /projects/:id/milestones/:milestone_id
@@ -137,7 +137,7 @@ Parameters:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53861) in GitLab 11.9
 
-Only for users with developer access to the group.
+Only for users with Developer access to the group.
 
 ```
 POST /projects/:id/milestones/:milestone_id/promote

doc/development/contributing/issue_workflow.md

@@ -29,7 +29,7 @@ the affected files to find someone.
 We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate
 some triaging policies. This is currently set up as a scheduled pipeline
 (`https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit`,
-must have at least developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
+must have at least Developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
 project.
 
 ## Labels

doc/development/documentation/workflow.md

@@ -284,7 +284,7 @@ To update GitLab documentation:
 1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
 
 TIP: **Tip:**
-Work in a fork if you do not have developer access to the GitLab project.
+Work in a fork if you do not have Developer access to the GitLab project.
 
 Request help from the Technical Writing team if you:
 

doc/development/policies.md

@@ -95,8 +95,8 @@ Each line represents a rule that was evaluated. There are a few things to note:
 
 Here you can see that the first four rules were evaluated `false` for
 which user and subject. For example, you can see in the last line that
-the rule was activated because the user `root` had at reporter access to
-the `Project/4`.
+the rule was activated because the user `root` had Reporter access to
+`Project/4`.
 
 When a policy is asked whether a particular ability is allowed
 (`policy.allowed?(:some_ability)`), it does not necessarily have to

doc/development/testing_guide/end_to_end/index.md

@@ -15,15 +15,15 @@ a black-box testing framework for the API and the UI.
 
 ### Testing nightly builds
 
-We run scheduled pipeline each night to test nightly builds created by Omnibus.
+We run scheduled pipelines each night to test nightly builds created by Omnibus.
 You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/nightly/pipelines`
 (need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
 
 ### Testing staging
 
-We run scheduled pipeline each night to test staging.
+We run scheduled pipelines each night to test staging.
 You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/staging/pipelines`
-(need developer access permissions). Results are reported in the `#qa-staging` Slack channel.
+(need Developer access permissions). Results are reported in the `#qa-staging` Slack channel.
 
 ### Testing code in merge requests
 

doc/user/project/new_ci_build_permissions_model.md

@@ -48,7 +48,7 @@ It is important to note that we have a few types of users:
   via another project's job.
 
 - **External users**: CI jobs created by [external users](../permissions.md#external-users-core-only) will have
-  access only to projects to which user has at least reporter access. This
+  access only to projects to which the user has at least Reporter access. This
   rules out accessing all internal projects by default.
 
 This allows us to make the CI and permission system more trustworthy.
@@ -114,7 +114,7 @@ docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com
 
 Using single token had multiple security implications:
 
-- The token would be readable to anyone who had developer access to a project
+- The token would be readable to anyone who had Developer access to a project
   that could run CI jobs, allowing the developer to register any specific
   Runner for that project.
 - The token would allow to access only the project's sources, forbidding from

doc/user/project/repository/repository_mirroring.md

@@ -22,7 +22,7 @@ There are two kinds of repository mirroring supported by GitLab:
 When the mirror repository is updated, all new branches, tags, and commits will be visible in the
 project's activity feed.
 
-Users with at least [developer access](../../permissions.md) to the project can also force an
+Users with at least [Developer access](../../permissions.md) to the project can also force an
 immediate update, unless:
 
 - The mirror is already being updated.