Skip to content

Commit dd347e3

Browse files
authored
Merge pull request #27801 from shuuji3/shuuji3/translate-contribute-review-27734
Translate contribute/review/for-approvers/ into Japanese
2 parents 3c1787a + c2234e1 commit dd347e3

File tree

1 file changed

+195
-0
lines changed

1 file changed

+195
-0
lines changed
Lines changed: 195 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,195 @@
1+
---
2+
title: approverとreviewer向けのレビュー
3+
linktitle: approverとreviewer向け
4+
slug: for-approvers
5+
content_type: concept
6+
weight: 20
7+
---
8+
9+
<!-- overview -->
10+
11+
SIG Docsの[Reviewer(レビュアー)](/docs/contribute/participate/#reviewers)[Approver(承認者)](/docs/contribute/participate/#approvers)は、変更をレビューする時にいくつか追加の作業を行います。
12+
13+
毎週、docsのメンバーの特定のapproverのボランティアは、pull requestのトリアージとレビューを担当します。この担当者は、その週の「PR Wrangler(PRの世話人)」と呼ばれます。詳しい情報は、[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)を参照してください。PR Wranglerになるには、週次のSIG Docsミーティングに参加し、ボランティアをします。もしその週にスケジュールされていなくても、活発なレビューが行われていないpull request(PR)をレビューすることは問題ありません。
14+
15+
このローテーションに加えて、変更されたファイルのオーナーに基づいて、botがPRにreviewerとapproverを割り当てます。
16+
17+
<!-- body -->
18+
19+
## PRをレビューする
20+
21+
Kubernetesのドキュメントは[Kubernetesコードレビュープロセス](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)に従います。
22+
23+
[pull requestのレビュー](/ja/docs/contribute/review/reviewing-prs/)に書かれているすべてのことが適用されますが、ReviewerとApproverはそれに加えて次のことも行います。
24+
25+
- 必要に応じて、`/assign`Prowコマンドを使用して、特定のreviewerにPRを割り当てる。これは、コードのコントリビューターからの技術的なレビューが必要な場合には特に重要です。
26+
27+
{{< note >}}
28+
技術的なレビューを行える人物を知るには、Markdownファイル上部にあるfront-matterの`reviewers`フィールドを確認してください。
29+
{{< /note >}}
30+
31+
- PRが[コンテンツ](/ja/docs/contribute/style/content-guide/)および[スタイル](/docs/contribute/style/style-guide/)のガイドに従っていることを確認してください。ガイドに従っていない場合は、ガイドの関連する部分にリンクを作者に示してください。
32+
- PRの作者に変更を提案できるときは、GitHubの**Request Changes**(変更をリクエスト)オプションを利用してください。
33+
- 提案したことが反映されたら、`/approve``/lgtm`コマンドを使用して、GitHubのレビューステータスを変更してください。
34+
35+
## 他の作者のPRにコミットを追加する
36+
37+
PRにコメントを残すのは助けになりますが、まれに他の作者のPRに代わりにコミットを追加する必要がある場合があります。
38+
39+
あなたが明示的に作者から頼まれたり、長い間放置されたPRを蘇らせるような場合でない限り、他の作者のPRを「乗っ取る」ようなことはしないでください。短期的に見ればそのほうが短時間で終わるかもしれませんが、そのようなことをするとその人が貢献するチャンスを奪ってしまうことになります。
40+
41+
あなたが取る方法は、編集する必要のあるファイルがすでにPRのスコープに入っているか、あるいはPRがまだ触れていないファイルであるかによって変わります。
42+
43+
以下のいずれかが当てはまる場合、他の作者のPRにあなたがコミットを追加することはできません。
44+
45+
- PRの作者が自分のブランチを直接[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)リポジトリにpushした場合。この場合、pushアクセス権限を持つreviewerしか他のユーザーのPRにコミットを追加することはできません。
46+
47+
{{< note >}}
48+
次回PRを作成するとき、自分のブランチを自分のforkに対してpushするように作者に促してください。
49+
{{< /note >}}
50+
51+
- PRの作者が明示的にapproverからの編集を禁止している場合。
52+
53+
## レビュー向けのProwコマンド
54+
55+
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)は、pull request(PR)に対してジョブを実行するKubernetesベースのCI/CDシステムです。Prowは、Kubernetes organization全体でchatbotスタイルのコマンドを利用してGitHub actionsを扱えるようにします。たとえば、[ラベルの追加と削除](#adding-and-removing-issue-labels)、issueのclose、approverの割り当てなどが行なえます。Prowコマンドは、GitHubのコメントに`/<command-name>`という形式で入力します。
56+
57+
reviewerとapproverが最もよく使うprowコマンドには、以下のようなものがあります。
58+
59+
{{< table caption="Prow commands for reviewing" >}}
60+
Prowコマンド | Roleの制限 | 説明
61+
:------------|:------------------|:-----------
62+
`/lgtm` | 誰でも。ただし、オートメーションがトリガされるのはReviewerまたはApproverが使用したときのみ。 | PRのレビューが完了し、変更に納得したことを知らせる。
63+
`/approve` | Approver | PRをマージすることを承認する。
64+
`/assign` | ReviewerまたはApprover | PRのレビューまたは承認するひとを割り当てる。
65+
`/close` | ReviewerまたはApprover | issueまたはPRをクローンする。
66+
`/hold` | 誰でも | `do-not-merge/hold`ラベルを追加して、自動的にマージできないPRであることを示す。
67+
`/hold cancel` | 誰でも | `do-not-merge/hold`ラベルを削除する。
68+
{{< /table >}}
69+
70+
PRで利用できるすべてのコマンド一覧を確認するには、[Prowコマンドリファレンス](https://prow.k8s.io/command-help)を参照してください。
71+
72+
## issueのトリアージとカテゴリー分類
73+
74+
一般に、SIG Docsは[Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md)のプロセスに従い、同じラベルを使用しています。
75+
76+
このGitHub issueの[フィルター](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)は、トリアージが必要な可能性があるissueを表示します。
77+
78+
### issueをトリアージする
79+
80+
1. issueを検証する
81+
- issueがドキュメントのウェブサイトに関係するものであることを確かめる。質問に答えたりリソースの場所を報告者に教えることですぐに閉じられるissueもあります。詳しくは、[サポートリクエストまたはコードのバグレポート](#support-requests-or-code-bug-reports)のセクションを読んでください。
82+
- issueにメリットがあるかどうか評価する。
83+
- issueに行動を取るのに十分な詳細情報がない場合や、テンプレートが十分埋められていない場合は、`triage/needs-information`ラベルを追加する。
84+
- `lifecycle/stale``triage/needs-information`の両方のラベルがあるときは、issueをcloseする。
85+
86+
2. 優先度(priority)ラベルを追加する([issueトリアージガイドライン](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)は、priorityラベルについて詳しく定義しています。)
87+
88+
{{< table caption="issueのラベル" >}}
89+
ラベル | 説明
90+
:------------|:------------------
91+
`priority/critical-urgent` | 今すぐに作業する。
92+
`priority/important-soon` | 3ヶ月以内に取り組む。
93+
`priority/important-longterm` | 6ヶ月以内に取り組む。
94+
`priority/backlog` | 無期限に延期可能。リソースに余裕がある時に取り組む。
95+
`priority/awaiting-more-evidence` | よいissueの可能性があるissueを見失わないようにするためのプレースホルダー。
96+
`help`または`good first issue` | KubernetesまたはSIG Docsでほとんど経験がない人に適したissue。より詳しい情報は、[Help WantedとGood First Issueラベル](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)を読んでください。
97+
{{< /table >}}
98+
99+
あなたの裁量で、issueのオーナーシップを取り、issueに対するPRを提出してください(簡単なissueや、自分がすでに行った作業に関連するissueである場合は特に)。
100+
101+
issueのトリアージについて質問があるときは、Slackの`#sig-docs`[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で質問してください。
102+
103+
## issueラベルの追加と削除 {#adding-and-removing-issue-labels}
104+
105+
ラベルを追加するには、以下のいずれかの形式でコメントします。
106+
107+
- `/<label-to-add>`(たとえば、`/good-first-issue`)
108+
- `/<label-category> <label-to-add>`(たとえば、`/triage needs-information``/language ja`)
109+
110+
ラベルを削除するには、以下のいずれかの形式でコメントします。
111+
112+
- `/remove-<label-to-remove>`(たとえば、`/remove-help`)
113+
- `/remove-<label-category> <label-to-remove>`(たとえば、`/remove-triage needs-information`)
114+
115+
いずれの場合でも、ラベルは既存のものでなければなりません。存在しないラベルを追加しようとした場合、コマンドは無視されます。
116+
117+
すべてのラベル一覧は、[websiteリポジトリーのラベルセクション](https://github.com/kubernetes/website/labels)で確認できます。SIG Docsですべてのラベルが使われているわけではありません。
118+
119+
### issueのライフサイクルに関するラベル
120+
121+
issueは一般にopen後に短期間でcloseされます。しかし、issueがopenされた後にアクティブでなくなったり、issueが90日以上openのままである場合もあります。
122+
123+
{{< table caption="issueのライブラリに関するラベル" >}}
124+
ラベル | 説明
125+
:------------|:------------------
126+
`lifecycle/stale` | 90日間活動がない場合、issueは自動的にstaleとラベル付けされます。`/remove-lifecycle stale`コマンドを使って手動でlifecycleをリバートしない限り、issueは自動的にcloseされます。
127+
`lifecycle/frozen` | このラベルが付けられたissueは、90日間活動がなくてもstaleになりません。`priority/important-longterm`ラベルを付けたissueなど、90日以上openにしておく必要があるissueには、このラベルを手動で追加します。
128+
{{< /table >}}
129+
130+
## 特別な種類のissueに対処する
131+
132+
SIG Docsでは、対処方法をドキュメントに書いても良いくらい頻繁に、以下のような種類のissueに出会います。
133+
134+
### 重服したissue
135+
136+
1つの問題に対して1つ以上のissueがopenしている場合、1つのissueに統合します。あなたはどちらのissueをopenにしておくか(あるいは新しいissueを作成するか)を決断して、すべての関連する情報を移動し、関連するすべてのissueにリンクしなければなりません。最後に、同じ問題について書かれたすべての他のissueに`triage/duplicate`ラベルを付けて、それらをcloseします。作業対象のissueを1つだけにすることで、混乱を晒し、同じ問題に対して作業が重複することを避けられます。
137+
138+
### リンク切れに関するissue
139+
140+
リンク切れのissueがAPIまたは`kubectl`のドキュメントにあるものは、問題が完全に理解されるまでは`/priority critical-urgent`を割り当ててください。その他のすべてのリンク切れに関するissueには、手動で修正が必要であるため、`/priority important-longterm`を付けます。
141+
142+
### Blogに関するissue
143+
144+
[Kubernetes Blog](https://kubernetes.io/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。
145+
146+
### サポートリクエストまたはコードのバグレポート {#support-requests-or-code-bug-reports}
147+
148+
一部のドキュメントのissueは、実際には元になっているコードの問題や、何か(たとえば、チュートリアル)がうまく動かないときにサポートをリクエストするものです。ドキュメントに関係のない問題は、`kind/support`ラベルを付け、サポートチャンネル(SlackやStack Overflowなど)へ報告者を導くコメントをして、もし関連があれば機能のバグに対するissueを報告するリポジトリ(`kubernetes/kubernetes`は始めるのに最適な場所です)を教えて、closeします。
149+
150+
サポートリクエストに対する返答の例を示します。(リクエストを行う際は英語で行うことが想定されるため、英文とその日本語訳を記載しています)
151+
152+
```none
153+
This issue sounds more like a request for support and less
154+
like an issue specifically for docs. I encourage you to bring
155+
your question to the `#kubernetes-users` channel in
156+
[Kubernetes slack](https://slack.k8s.io/). You can also search
157+
resources like
158+
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
159+
for answers to similar questions.
160+
161+
You can also open issues for Kubernetes functionality in
162+
https://github.com/kubernetes/kubernetes.
163+
164+
If this is a documentation issue, please re-open this issue.
165+
```
166+
167+
```none
168+
このissueは特定のドキュメントに関するissueではなく、サポートリクエストのようです。
169+
Kubernetesに関する質問については、[Kubernetes slack](https://slack.k8s.io/)の
170+
`#kubernetes-users`チャンネルに投稿することをおすすめします。同様の質問に対する回答を
171+
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)などの
172+
リソースで検索することもできます。
173+
174+
Kubernetesの機能に関するissueについては、https://github.com/kubernetes/kubernetes
175+
でissueを作成できます。
176+
177+
もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。
178+
```
179+
180+
コードのバグに対する返答の例を示します。
181+
182+
```none
183+
This sounds more like an issue with the code than an issue with
184+
the documentation. Please open an issue at
185+
https://github.com/kubernetes/kubernetes/issues.
186+
187+
If this is a documentation issue, please re-open this issue.
188+
```
189+
190+
```none
191+
こちらのissueは、ドキュメントではなくコードに関係するissueのようです。
192+
https://github.com/kubernetes/kubernetes/issues でissueを作成してください。
193+
194+
もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。
195+
```

0 commit comments

Comments
 (0)