Skip to content
Browse files

Update contribution guidelines for approvers (#15385)

  • Loading branch information...
zacharysarah authored and k8s-ci-robot committed Jul 12, 2019
1 parent 00d9ada commit 0e540e8dcb827239479eeb8885e1beefb6b9f39e
@@ -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`]( 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
conform to those outlined in the
[Kubernetes contributor guide](, and can be one of `P1`, `P2`, or `P3`, if set.
- 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
- Priority labels: define the relative severity of the issue, as outlined in the
[Kubernetes contributor guide](
- To add a label, leave 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
dead links are issues that need to be manually fixed and can be assigned a P3.
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 `/priority important-longterm`.

#### Blog issues

@@ -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
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.
Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities:

If you think you need this level of access, talk to an existing website admin or
ask in the #sig-docs channel on [Kubernetes Slack](
- Approvers can use the `/approve` command, which merges PRs into the repo.

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](
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.
Binary file not shown.

0 comments on commit 0e540e8

Please sign in to comment.
You can’t perform that action at this time.