Skip to content

Commit fb49858

Browse files
shuuji3shuuji3
committed
Copy content/en/docs/contribute/review/for-approvers.md for translation
1 parent 582d97b commit fb49858

File tree

1 file changed

+225
-0
lines changed

1 file changed

+225
-0
lines changed

‎content/ja/docs/contribute/review/for-approvers.md

Lines changed: 225 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,225 @@
1+
---
2+
title: Reviewing for approvers and reviewers
3+
linktitle: For approvers and reviewers
4+
slug: for-approvers
5+
content_type: concept
6+
weight: 20
7+
---
8+
9+
<!-- overview -->
10+
11+
SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
12+
[Approvers](/docs/contribute/participate/#approvers) do a few extra things
13+
when reviewing a change.
14+
15+
Every week a specific docs approver volunteers to triage
16+
and review pull requests. This
17+
person is the "PR Wrangler" for the week. See the
18+
[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull
19+
requests (PRs) that are not already under active review.
20+
21+
In addition to the rotation, a bot assigns reviewers and approvers
22+
for the PR based on the owners for the affected files.
23+
24+
<!-- body -->
25+
26+
## Reviewing a PR
27+
28+
Kubernetes documentation follows the [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process).
29+
30+
Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs) applies, but Reviewers and Approvers should also do the following:
31+
32+
- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed. This is extra important
33+
when it comes to requesting technical review from code contributors.
34+
35+
{{< note >}}
36+
Look at the `reviewers` field in the front-matter at the top of a Markdown file to see who can
37+
provide technical review.
38+
{{< /note >}}
39+
40+
- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/) and [Style](/docs/contribute/style/style-guide/) guides; link the author to the relevant part of the guide(s) if it doesn't.
41+
- Using the GitHub **Request Changes** option when applicable to suggest changes to the PR author.
42+
- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands, if your suggestions are implemented.
43+
44+
## Commit into another person's PR
45+
46+
Leaving PR comments is helpful, but there might be times when you need to commit
47+
into another person's PR instead.
48+
49+
Do not "take over" for another person unless they explicitly ask
50+
you to, or you want to resurrect a long-abandoned PR. While it may be faster
51+
in the short term, it deprives the person of the chance to contribute.
52+
53+
The process you use depends on whether you need to edit a file that is already
54+
in the scope of the PR, or a file that the PR has not yet touched.
55+
56+
You can't commit into someone else's PR if either of the following things is
57+
true:
58+
59+
- If the PR author pushed their branch directly to the
60+
[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)
61+
repository. Only a reviewer with push access can commit to another user's PR.
62+
63+
{{< note >}}
64+
Encourage the author to push their branch to their fork before
65+
opening the PR next time.
66+
{{< /note >}}
67+
68+
- The PR author explicitly disallows edits from approvers.
69+
70+
## Prow commands for reviewing
71+
72+
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is
73+
the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow
74+
enables chatbot-style commands to handle GitHub actions across the Kubernetes
75+
organization, like [adding and removing labels](#adding-and-removing-issue-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format.
76+
77+
The most common prow commands reviewers and approvers use are:
78+
79+
{{< table caption="Prow commands for reviewing" >}}
80+
Prow Command | Role Restrictions | Description
81+
:------------|:------------------|:-----------
82+
`/lgtm` | Anyone, but triggers automation if a Reviewer or Approver uses it | Signals that you've finished reviewing a PR and are satisfied with the changes.
83+
`/approve` | Approvers | Approves a PR for merging.
84+
`/assign` | Reviewers or Approvers | Assigns a person to review or approve a PR
85+
`/close` | Reviewers or Approvers | Closes an issue or PR.
86+
`/hold` | Anyone | Adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged.
87+
`/hold cancel` | Anyone | Removes the `do-not-merge/hold` label.
88+
{{< /table >}}
89+
90+
See [the Prow command reference](https://prow.k8s.io/command-help) to see the full list
91+
of commands you can use in a PR.
92+
93+
## Triage and categorize issues
94+
95+
96+
In general, SIG Docs follows the [Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) process and uses the same labels.
97+
98+
99+
This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)
100+
finds issues that might need triage.
101+
102+
### Triaging an issue
103+
104+
1. Validate the issue
105+
- Make sure the issue is about website documentation. Some issues can be closed quickly by
106+
answering a question or pointing the reporter to a resource. See the
107+
[Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details.
108+
- Assess whether the issue has merit.
109+
- Add the `triage/needs-information` label if the issue doesn't have enough
110+
detail to be actionable or the template is not filled out adequately.
111+
- Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels.
112+
113+
2. Add a priority label (the
114+
[Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) define priority labels in detail)
115+
116+
{{< table caption="Issue labels" >}}
117+
Label | Description
118+
:------------|:------------------
119+
`priority/critical-urgent` | Do this right now.
120+
`priority/important-soon` | Do this within 3 months.
121+
`priority/important-longterm` | Do this within 6 months.
122+
`priority/backlog` | Deferrable indefinitely. Do when resources are available.
123+
`priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost.
124+
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information.
125+
126+
{{< /table >}}
127+
128+
At your discretion, take ownership of an issue and submit a PR for it
129+
(especially if it's quick or relates to work you're already doing).
130+
131+
If you have questions about triaging an issue, ask in `#sig-docs` on Slack or
132+
the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
133+
134+
## Adding and removing issue labels
135+
136+
To add a label, leave a comment in one of the following formats:
137+
138+
- `/<label-to-add>` (for example, `/good-first-issue`)
139+
- `/<label-category> <label-to-add>` (for example, `/triage needs-information` or `/language ja`)
140+
141+
To remove a label, leave a comment in one of the following formats:
142+
143+
- `/remove-<label-to-remove>` (for example, `/remove-help`)
144+
- `/remove-<label-category> <label-to-remove>` (for example, `/remove-triage needs-information`)`
145+
146+
In both cases, the label must already exist. If you try to add a label that does not exist, the command is
147+
silently ignored.
148+
149+
For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels). Not all labels are used by SIG Docs.
150+
151+
### Issue lifecycle labels
152+
153+
Issues are generally opened and closed quickly.
154+
However, sometimes an issue is inactive after its opened.
155+
Other times, an issue may need to remain open for longer than 90 days.
156+
157+
{{< table caption="Issue lifecycle labels" >}}
158+
Label | Description
159+
:------------|:------------------
160+
`lifecycle/stale` | After 90 days with no activity, an issue is automatically labeled as stale. The issue will be automatically closed if the lifecycle is not manually reverted using the `/remove-lifecycle stale` command.
161+
`lifecycle/frozen` | An issue with this label will not become stale after 90 days of inactivity. A user manually adds this label to issues that need to remain open for much longer than 90 days, such as those with a `priority/important-longterm` label.
162+
{{< /table >}}
163+
164+
## Handling special issue types
165+
166+
SIG Docs encounters the following types of issues often enough to document how
167+
to handle them.
168+
169+
### Duplicate issues
170+
171+
If a single problem has one or more issues open for it, combine them into a single issue.
172+
You should decide which issue to keep open (or
173+
open a new issue), then move over all relevant information and link related issues.
174+
Finally, label all other issues that describe the same problem with
175+
`triage/duplicate` and close them. Only having a single issue to work on reduces confusion
176+
and avoids duplicate work on the same problem.
177+
178+
### Dead link issues
179+
180+
If the dead link issue is in the API or `kubectl` documentation, assign them `/priority critical-urgent` until the problem is fully understood. Assign all other dead link issues `/priority important-longterm`, as they must be manually fixed.
181+
182+
### Blog issues
183+
184+
We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become
185+
outdated over time. Therefore, we only maintain blog entries less than a year old.
186+
If an issue is related to a blog entry that is more than one year old,
187+
close the issue without fixing.
188+
189+
### Support requests or code bug reports
190+
191+
Some docs issues are actually issues with the underlying code, or requests for
192+
assistance when something, for example a tutorial, doesn't work.
193+
For issues unrelated to docs, close the issue with the `kind/support` label and a comment
194+
directing the requester to support venues (Slack, Stack Overflow) and, if
195+
relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
196+
is a great place to start).
197+
198+
Sample response to a request for support:
199+
200+
```none
201+
This issue sounds more like a request for support and less
202+
like an issue specifically for docs. I encourage you to bring
203+
your question to the `#kubernetes-users` channel in
204+
[Kubernetes slack](https://slack.k8s.io/). You can also search
205+
resources like
206+
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
207+
for answers to similar questions.
208+
209+
You can also open issues for Kubernetes functionality in
210+
https://github.com/kubernetes/kubernetes.
211+
212+
If this is a documentation issue, please re-open this issue.
213+
```
214+
215+
Sample code bug report response:
216+
217+
```none
218+
This sounds more like an issue with the code than an issue with
219+
the documentation. Please open an issue at
220+
https://github.com/kubernetes/kubernetes/issues.
221+
222+
If this is a documentation issue, please re-open this issue.
223+
```
224+
225+

0 commit comments

Comments
 (0)