1 files changed, 7 insertions, 4 deletions
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index c5f49fd6e59..cea6f26181f 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -1,4 +1,7 @@
 ---
+stage: Release
+group: Progressive Delivery
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: tutorial
 ---
 
@@ -44,7 +47,7 @@ All these operations will put all files into a `build` folder, which is ready to
 
 ## How to transfer files to a live server
 
-You have multiple options: rsync, scp, sftp, and so on. For now, we will use scp.
+You have multiple options: rsync, SCP, SFTP, and so on. For now, we will use SCP.
 
 To make this work, you need to add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** SSH key of your server.
 
@@ -74,7 +77,7 @@ And this is basically all you need in the `before_script` section.
 
 ## How to deploy
 
-As we stated above, we need to deploy the `build` folder from the docker image to our server. To do so, we create a new job:
+As we stated above, we need to deploy the `build` folder from the Docker image to our server. To do so, we create a new job:
 
 ```yaml
 stage_deploy:
@@ -94,7 +97,7 @@ stage_deploy:
 Here's the breakdown:
 
 1. `only:dev` means that this build will run only when something is pushed to the `dev` branch. You can remove this block completely and have everything be ran on every push (but probably this is something you don't want)
-1. `ssh-add ...` we will add that private key you added on the web UI to the docker container
+1. `ssh-add ...` we will add that private key you added on the web UI to the Docker container
 1. We will connect via `ssh` and create a new `_tmp` folder
 1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
 1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
@@ -120,7 +123,7 @@ Therefore, for a production environment we use additional steps to ensure that a
 Since this was a WordPress project, I gave real life code snippets. Some further ideas you can pursue:
 
 - Having a slightly different script for `master` branch will allow you to deploy to a production server from that branch and to a stage server from any other branches.
-- Instead of pushing it live, you can push it to WordPress official repo (with creating a SVN commit, etc.).
+- Instead of pushing it live, you can push it to WordPress official repository (with creating a SVN commit, etc.).
 - You could generate i18n text domains on the fly.
 
 ---