Add latest changes from gitlab-org/gitlab@13-5-stable-eev13.5.0-rc42

2 files changed, 23 insertions, 23 deletions

diff --git a/doc/user/packages/workflows/monorepo.md b/doc/user/packages/workflows/monorepo.md
index c87f181bf82..f20f3427ac5 100644
--- a/doc/user/packages/workflows/monorepo.md
+++ b/doc/user/packages/workflows/monorepo.md
@@ -7,17 +7,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Monorepo package management workflows
 
 Oftentimes, one project or Git repository may contain multiple different
-subprojects or submodules that all get packaged and published individually.
+sub-projects or submodules that all get packaged and published individually.
 
 ## Publishing different packages to the parent project
 
 The number and name of packages you can publish to one project is not limited.
 You can accomplish this by setting up different configuration files for each
 package. See the documentation for the package manager of your choice since
-each will have its own specific files and instructions to follow to publish
+each has its own specific files and instructions to follow to publish
 a given package.
 
-Here, we will walk through how to do this with [NPM](../npm_registry/index.md).
+Here, we take a walk through how to do this with [NPM](../npm_registry/index.md).
 
 Let us say we have a project structure like so:
 
@@ -36,27 +36,27 @@ as well as `Foo`.
 Following the instructions in the
 [GitLab NPM registry documentation](../npm_registry/index.md),
 publishing `MyProject` consists of modifying the `package.json` file with a
-`publishConfig` section, as well as either modifying your local NPM config with
+`publishConfig` section, as well as either modifying your local NPM configuration with
 CLI commands like `npm config set`, or saving a `.npmrc` file in the root of the
-project specifying these config settings.
+project specifying these configuration settings.
 
 If you follow the instructions you can publish `MyProject` by running
 `npm publish` from the root directory.
 
 Publishing `Foo` is almost exactly the same, you simply have to follow the steps
-while in the `Foo` directory. `Foo` will need its own `package.json` file,
-which can be added manually or using `npm init`. And it will need its own
+while in the `Foo` directory. `Foo` needs its own `package.json` file,
+which can be added manually or using `npm init`. It also needs its own
 configuration settings. Since you are publishing to the same place, if you
 used `npm config set` to set the registry for the parent project, then no
-additional setup is necessary. If you used a `.npmrc` file, you will need an
+additional setup is necessary. If you used a `.npmrc` file, you need an
 additional `.npmrc` file in the `Foo` directory (be sure to add `.npmrc` files
 to the `.gitignore` file or use environment variables in place of your access
 tokens to prevent them from being exposed). It can be identical to the
 one you used in `MyProject`. You can now run `npm publish` from the `Foo`
-directory and you will be able to publish `Foo` separately from `MyProject`
+directory and you can publish `Foo` separately from `MyProject`
 
 A similar process could be followed for Conan packages, instead of dealing with
-`.npmrc` and `package.json`, you will just be dealing with `conanfile.py` in
+`.npmrc` and `package.json`, you just deal with `conanfile.py` in
 multiple locations within the project.
 
 ## Publishing to other projects
@@ -64,9 +64,9 @@ multiple locations within the project.
 A package is associated with a project on GitLab, but the package does not
 need to be associated with the code in that project. Notice when configuring
 NPM or Maven, you only use the `Project ID` to set the registry URL that the
-package will be uploaded to. If you set this to any project that you have
-access to and update any other config similarly depending on the package type,
-your packages will be published to that project. This means you can publish
+package is to be uploaded to. If you set this to any project that you have
+access to and update any other configuration similarly depending on the package type,
+your packages are published to that project. This means you can publish
 multiple packages to one project, even if their code does not exist in the same
 place. See the [project registry workflow documentation](./project_registry.md)
 for more details.
@@ -77,7 +77,7 @@ CI pipelines open an entire world of possibilities for dealing with the patterns
 described in the previous sections. A common desire would be to publish
 specific packages only if changes were made to those directories.
 
-Using the example project above, this `gitlab-ci.yml` file will publish
+Using the example project above, this `gitlab-ci.yml` file publishes
 `Foo` anytime changes are made to the `Foo` directory on the `master` branch,
 and publish `MyPackage` anytime changes are made to anywhere _except_ the `Foo`
 directory on the `master` branch.
diff --git a/doc/user/packages/workflows/project_registry.md b/doc/user/packages/workflows/project_registry.md
index 571cda09e69..24437e6dfac 100644
--- a/doc/user/packages/workflows/project_registry.md
+++ b/doc/user/packages/workflows/project_registry.md
@@ -26,8 +26,8 @@ point them at the same project on GitLab.
 There are a few reasons you might want to publish all your packages to one project on GitLab:
 
 1. You want to publish your packages on GitLab, but to a project that is different from where your code is stored.
-1. You would like to group packages together in ways that make sense for your usage (all NPM packages in one project,
-   all packages being used by a specific department in one project, all private packages in one project, etc.)
+1. You would like to group packages together in ways that make sense for your usage (such as all NPM packages in one project,
+   all packages being used by a specific department in one project, or all private packages in one project)
 1. You want to use one remote for all of your packages when installing them into other projects.
 1. You would like to migrate your packages to a single place on GitLab from a third-party package registry and do not
    want to worry about setting up separate projects for each package.
@@ -44,7 +44,7 @@ Let's take a look at how you might create a public place to hold all of your pub
 ### Create a project
 
 First, create a new project on GitLab. It does not have to have any code or content. Make note of the project ID
-displayed on the project overview page, as you will need this later.
+displayed on the project overview page for use later in this process.
 
 ### Create an access token
 
@@ -67,24 +67,24 @@ If you are using NPM, this involves creating an `.npmrc` file and adding the app
 to your project using your project ID, then adding a section to your `package.json` file with a similar URL.
 
 Follow
-the instructions in the [GitLab NPM Registry documentation](../npm_registry/index.md#authenticating-to-the-gitlab-npm-registry). Once
-you do this, you will be able to push your NPM package to your project using `npm publish`, as described in the
+the instructions in the [GitLab NPM Registry documentation](../npm_registry/index.md#authenticating-to-the-gitlab-npm-registry). After
+you do this, you can push your NPM package to your project using `npm publish`, as described in the
 [uploading packages](../npm_registry/index.md#uploading-packages) section of the docs.
 
 #### Maven
 
 If you are using Maven, this involves updating your `pom.xml` file with distribution sections, including the
 appropriate URL for your project, as described in the [GitLab Maven Repository documentation](../maven_repository/index.md#project-level-maven-endpoint).
-Then, you need to add a `settings.xml` file and [include your access token](../maven_repository/index.md#authenticating-with-a-personal-access-token).
+Then, you need to add a `settings.xml` file and [include your access token](../maven_repository/index.md#authenticate-with-a-personal-access-token).
 Now you can [deploy Maven packages](../maven_repository/index.md#uploading-packages) to your project.
 
 #### Conan
 
-For Conan, first you need to add GitLab as a Conan registry remote. Follow the instructions in the [GitLab Conan Repository docs](../conan_repository/index.md#adding-the-gitlab-package-registry-as-a-conan-remote)
+For Conan, first you need to add GitLab as a Conan registry remote. Follow the instructions in the [GitLab Conan Repository docs](../conan_repository/index.md#add-the-package-registry-as-a-conan-remote)
 to do so. Then, create your package using the plus-separated (`+`) project path as your Conan user. For example,
 if your project is located at `https://gitlab.com/foo/bar/my-proj`, then you can [create your Conan package](../conan_repository/index.md)
-using `conan create . foo+bar+my-proj/channel`, where `channel` is your package channel (`stable`, `beta`, etc.). Once your package
-is created, you are ready to [upload your package](../conan_repository/index.md#uploading-a-package) depending on your final package recipe. For example:
+using `conan create . foo+bar+my-proj/channel`, where `channel` is your package channel (such as `stable` or `beta`). After your package
+is created, you are ready to [upload your package](../conan_repository/index.md#publish-a-conan-package) depending on your final package recipe. For example:
 
 ```shell
 CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan upload MyPackage/1.0.0@foo+bar+my-proj/channel --all --remote=gitlab