Update contribution guidelines for approvers (#15385)

content/en/docs/contribute/intermediate.md

@@ -109,13 +109,19 @@ more information about the responsibilities of reviewers and approvers, see
   [style guide](/docs/contribute/style/style-guide). Only people listed as
   approvers in the
   [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) file can
-  approve a PR. To approve a PR, leave an `/approved` comment on the PR.
+  approve a PR. To approve a PR, leave an `/approve` comment on the PR.
 
 A PR is merged when it has both a `/lgtm` comment from anyone in the Kubernetes
 organization and an `/approved` comment from an approver in the
 `sig-docs-maintainers` group, as long as it is not on hold and the PR author
 has signed the CLA.
 
+{{< note >}}
+
+The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers.
+
+{{< /note >}}
+
 ### Review a PR
 
 1.  Read the PR description and read any attached issues or links, if
@@ -575,45 +581,15 @@ These guidelines are not set in stone and are subject to change.
     not be assigned automatically. A bug is a problem with existing content or
     functionality, and a feature is a request for new content or functionality.
     The `kind/documentation` label is not currently in use.
-  - Priority labels: define the relative severity of the issue. These do not
+  - Priority labels: define the relative severity of the issue, as outlined in the
-    conform to those outlined in the
+    [Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority).
-    [Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority), and can be one of `P1`, `P2`, or `P3`, if set.
+- To add a label, leave a comment like `/label <label-to-add>`. The label must
-- To add a label, you can use GitHub's **Labels** widget if you are a Sig Docs
-  approver. Anyone who is a member of the Kubernetes organization can add a
-  label by leaving a comment like `/label <label-to-add>`. The label must
   already exist. If you try to add a label that does not exist, the command is
   silently ignored.
 
-### Priorities
-
-An issue's priority influences how quickly it is addressed. For documentation,
-here are the guidelines for setting a priority on an issue:
-
-#### P1
-
-- Major content errors affecting more than 1 page
-- Broken code sample on a heavily trafficked page
-- Errors on a “getting started” page
-- Well known or highly publicized customer pain points
-- Automation issues
-
-#### P2
-
-This is the default for new issues and pull requests.
-
-- Broken code for sample that is not heavily used
-- Minor content issues in a heavily trafficked page
-- Major content issues on a lower-trafficked page
-
-#### P3
-
-- Typos and broken anchor links
-- Documentation feature requests
-- "Nice to have" items
-
 ### Handling special issue types
 
-We've encountered the following types of issues often enough to document how
+We encounter the following types of issues often enough to document how
 to handle them.
 
 #### Duplicate issues
@@ -629,8 +605,8 @@ same problem.
 
 Depending on where the dead link is reported, different actions are required to
 resolve the issue. Dead links in the API and Kubectl docs are automation issues
-and should be assigned a P1 until the problem can be fully understood. All other
+and should be assigned `/priority critical-urgent` until the problem can be fully understood. All other
-dead links are issues that need to be manually fixed and can be assigned a P3.
+dead links are issues that need to be manually fixed and can be assigned `/priority important-longterm`.
 
 #### Blog issues
 

content/en/docs/contribute/participating.md

@@ -201,21 +201,29 @@ If you are approved, request that a current SIG Docs approver add you to the
 GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
 add new members to a GitHub group.
 
-#### Becoming a website admin
+#### Approver responsibilities
 
-Members of the `kubernetes-website-admins` GitHub group can manage GitHub group
+Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities:
-membership and have full administrative rights to the settings of the repository,
-including the ability to add, remove, and troubleshoot webhooks. Not all SIG
-Docs approvers need this level of access.
 
-If you think you need this level of access, talk to an existing website admin or
+- Approvers can use the `/approve` command, which merges PRs into the repo.
-ask in the #sig-docs channel on [Kubernetes Slack](https://kubernetes.slack.com).
+
+    A careless merge can break the site, so be sure that when you merge something, you mean it.
+    
+- Make sure that proposed changes meet the contribution guidelines. 
+
+    If you ever have a question, or you're not sure about something, feel free to call for additional review.
+
+- Verify that netlify tests pass before you `/approve` a PR.
+
+    <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" />
+
+- Visit the netlify page preview for a PR to make sure things look good before approving.
 
 #### PR Wrangler
 
-SIG Docs approvers are added to the
+SIG Docs approvers participate in the
 [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
-for weekly rotations. All SIG Docs approvers are expected to take part in this
+for weekly rotations. SIG Docs expects all approvers to participate in this
 rotation. See
 [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
 for more details.