Commit 7a0b1cac authored by Evan Read's avatar Evan Read

Merge branch 'fix-plurality-capitalization-documentation' into 'master'

Fix plurality and capitalization in the documentation

See merge request gitlab-org/gitlab!22393
parents 81136b97 2fd2d2e5
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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:
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment