こんにちは。
Kubernetes SIG SchedulingのReviewerになりました✌️https://t.co/doTTvANDRO
— さんぽし/sanposhiho (@sanpo_shiho) May 10, 2022
今日はこの話をします。
Kubernetes コミュニティのロールについて
Reviewerってなんぞやという話なのですが、Kubernetesコミュニティ上のロールの一つです。
community/community-membership.md · kubernetes/community
Kubernetesコミュニティ上にはロールは大きく分けて3つ存在します。
- Member
- Reveiwer
- Approver
上記のドキュメントに全てが書かれているので、ざっくりとだけ説明すると。
Member
Kubernetes GitHub Organization のメンバーです。
幾つかKubernetesコミュニティ上の何かのプロジェクトにcontributeして、Sponsorとなってくれる人を二人以上見つけることができればなれます。
割とハードルは低く、Kubernetes本体(kubernetes/kubernetes)だけではなく、websiteやKubernetes Org以外のOrganizationのプロジェクトなど任意のサブプロジェクトにcontributeしていれば、なることができます。
コミュニティへの貢献の形は人それぞれで、kubernetes/kubernetesに貢献している人だけが偉いわけでは全くないので、気になっている人は自分が参加できそうなプロジェクトから始めてみるといいと思います。 (例えば、公式ドキュメントの日本語訳などは足りていない部分がいくつかあるので、そこからチャレンジしてみるとか。)
恐らく最も難しいのが、contributeすることよりもSponsorとなってくれる人を探すことだと思います。Sponsorになることができる人には条件(この辺り参照)があります。
こんな感じのPRを出すことでmemberになることができます。
REQUEST: New membership for @sanposhiho · Issue #2901 · kubernetes/org
Reviewer
ReviewerやApproverは、プロジェクト単位で用意されているものやフォルダ単位で管理されているものなどがあり、OWNERSファイルというものを通して、管理されます。
KubernetesにはSIGと呼ばれる多くなチーム単位があります。SIGはSpecial Interest Groupsの略称で、Kubernetesは領域ごとにチームに分かれて開発されています。(例えば、SchedulerはSIG-Schedulingの担当領域です。)
そして、Kubernetes本体(kubernetes/kubernetes)に関しては、SIGごとにReviewer/ApproverがOWNERS_ALIASESで定義され、「このフォルダ内はSIG-XXXXXのもの」みたいな形で管理されていることが多いです。(例: scheduler)
Reviewerは頑張って特定の領域にcontributeし続け、条件を全て満たした場合になることができます。
恐らく最も大きな壁は、「20個以上のレビューがついた or マージされたPRを作る」「5つのPRをレビューする」あたりな気がします。 例えば、SIG-SchedulingのReviewerになりたいのであれば、sig/schedulingのラベルがついたPRが対象となります。サブプロジェクトだと例えば、kubebuilderのOWNERになりたいのであれば、kubebuilder上の全てのPRが対象になります。
条件を満たしたなと思ったら、こんな感じでPRを作って、マージされると晴れてReviwersの仲間入りです。 Add sanposhiho to SIG Scheduling reviewers by sanposhiho · Pull Request #109888 · kubernetes/kubernetes
Approver
ApproverはPRを承認できる権限です。つまり、己の判断でコードに変更を入れることができるようになります、すごい。
Reviewer同様に、頑張って特定の領域にcontributeし続け、条件を全て満たした場合になることができます。
実は上記の条件を満たすのはReviewerになった人だとそれほど大変な道のりではないです。(+10個のPR作成,+5個のPRレビュー等)
しかし、Approverはかなりの責任を伴い強い権限をもつロールなので、個人的には怖く感じちゃいますね。
お前はここまで何をやったん?
僕は昨年の春頃に「Google Summer of Codeに申し込もう！」と思い立って、Kubernetesにcontributeを始めたのが一番最初でした。
Google Summer of Code 2021 で Kubernetes に出していたProposalが採択された
↓が一番最初に作ったPRっぽいですね。昨年の5/8です。(先日やっと一年越しにマージされていますね ^^;)
このGoogle Summber of Codeで作ったプロジェクトは現在SIG-Schedulingのサブプロジェクトとしてメンテナンスされていて、kubernetes-sigs/kube-scheduler-simulatorです。 (こちらに関しては、僕が0から作ったものなので、初めからApproverを持っています。)
GSoCを終えた後もちまちまと、kubernetes/kubernetesへのcontributeを続け、SIG-SchedulingのReviewerの条件を満たしました。
ReviewerのPRを作成した時点で、SIG-Schedulingの対象のもので、
- 14個のPRのレビュー
- 21個のマージされたPR、3個のレビューされたPRの作成
をしていたようです。
最も大きかった仕事はMinDomainsのKEPだと思います。先週書いた記事↓です。
Kubernetes へ MinDomains という機能の KEP を出し、それがalpha機能としてリリースされた話
あとは、scheduler_perfというSchedulerのパフォーマンス計測のためのツールがあるのですが、この辺りはとてもよく触っていました。 メンテナーの中でもかなり実装に詳しい方だと思います。(GSoCのメンターだった人がscheduler_perfの作者だったという背景があります。kube-scheduler-simulatorもここから着想を得たものです。)
終わりに
僕は初めてPRを作ってから丁度1年ほどでReviewerになったことになります。これが遅いのか早いのかは分かりませんが、偶然僕と同じ頃からSchedulerにcontributeを初めてちょうど同じ頃にReviewerになった方を知っているので、遅くも早くもないんじゃないかなと思っています。
この遅い早いの話はどうでもよくて、ちまちま続けているだけである程度のロールのメンテナになれるということです。さてそろそろ「この小童でもできるなら、わしもKubernetesコントリビュートできそうやん」と思い始めた頃じゃないですか？
個人的には、kubernetes/kubernetesにcontributeするなら、テストの追加やコードのリファクタリングから始めることをお勧めしています。(good-first issueはめちゃめちゃ倍率が高いです。)
前述のように、websiteなどのkubernetes/kubernetes以外のプロジェクトへの貢献から始めるのも、いいと思います。 kubernetes-sigs/kube-scheduler-simulatorのコントリビューターも大募集しています。
