はじめに
2021年7月某日、SwiftのCommit Accessをゲットしました。
それを自慢するため、 Commit Accessの輪が広がったらいいなという期待を込めて、Commit Accessを付与してもらう方法を記事にします。
Commit AccessはSwiftに貢献するための手段であって目的ではありませんが、本記事では構成上それをゴールとして、ゴールに辿り着くまでを遡って書いていくことにします。
Commit Access is 何？
詳細は公式サイトの説明をご覧いただくとして…、簡単に説明すると、Commit Accessとは“Swiftプロジェクトの主たるGitHubレポジトリ1に直接コミットできちゃう権利”です。当該レポジトリのPull Requestをマージしちゃうこともできます(もちろんルールを守ってね)。
そして、SwiftのCIを動かすことができるのも、Commit Accessを持ったユーザだけです。PRをオープンしただけでは勝手にCIが動くことはなく、Commit Accessを持ったユーザにCIを動かしてもらう必要があるのです。個人的には、これがちょっと面倒に感じていました。少し修正したりrebaseしたりする度に、「申し訳ありませんが、CIを始動させてもらえませんかねぇ」とお願いすることになります。
当初はAppleの中の人だけがCommit Accessを有していましたが、2016年初めごろにApple外の人にも付与されることになりました2。
Commit Accessをゲットする道のり(を遡る)
Commit Accessが付与される条件
条件はすごく単純です。必要なのは次の要件のみ3：
5 non-trivial pull requests that were accepted without modifications
修正無しで認められた些細ではない4PRが5つあればOKなのです。
Pull Requestを送ればいいんだ
というわけで、Commit Accessを得るためにはPRを送ればいいことが分かりました。
ただ、“修正無しで”というのが多少厄介かもしれません。皆さんも経験されているとは思いますが、PRのレビューで「ここをちょっと直して」なんてことを言われるのは日常茶飯事でしょう。
修正無しで承認されるPRを5つ用意するには、その倍以上のPRが必要となるかもしれません。なるべく修正が入らないように、「実装＆実装箇所に対応するテストを追加→ローカルでテストが通ることを確認→PRオープン」という(当たり前といえば当たり前の)手順をしっかり踏むことが大切でしょう。
あと、Swift.orgの"Contributing Code"もよく読んでね。
Pull Requestをたくさん送るには
SwiftプロジェクトにおけるPRで主要なのは①新機能追加と②バグ修正でしょう。
ただ、①についてはSwift Evolutionのプロセスを経る必要があり、(少なくとも筆者のようなペーペーには)かなり険しい茨の道。
ここは②でPR数を稼ぐのが現実的でしょう。
(補記) Pull Requestは途中で諦めても良い！
Apple(Swiftプロジェクト)におけるPRに対する姿勢はかなり寛容です。
gitに不慣れでも、その使い方から教えてくれたりすることもあります。
PRのレビューで修正を求められて、「やっぱりできない！」と思ったら諦めることもできます。
docs/HowToGuides/FirstPullRequest.mdには次のように書かれています:
I can't finish the contribution I started. ☹️
That's totally okay! There is no shame in that. You only have limited time and energy in a day. If you can, leave a comment on the bug report/pull request that you will not be able to continue and unassign yourself from the bug on JIRA. Don't worry about trying to explain why you aren't able to contribute further. We understand. Unanticipated things come up all the time and you should do what works for you.
This point also applies if you don't have time right now but hope to get to something in the near future. Please don't feel sad or apologetic!
(YOCKOW拙訳)
最後までできないよぅ。☹️
全く問題はありません！恥じることもありません。1日に使える時間も体力も限界があります。もし可能なら、バグレポート/プルリクエストにもう続けられないというコメントを残し、JIRA上で自分の割り当てを解除してください。これ以上貢献できない理由について説明しようと気を揉むことはありません。我々は理解しています。予期せぬ事態はいつでも起きるので、自分のためにできることをすべきです。
このことは、今は時間がないけど近いうちに着手できたらいいなという場合にも当てはまります。悲しんだり申し訳なく思ったりしないでください！
Swiftのバグ？
Swiftのバグ修正でPRを送るためには、当然まずはSwiftのバグを知る必要があります。
Swiftプロジェクトでは、バグの管理にGitHubの"issues"は使われず、JIRAが使われています。URLは https://bugs.swift.org/ です。
追記: 2022年4月以降はSwiftプロジェクトでもGitHub issuesが使われることとなりました5。
ここから自分でも修正できそうなバグ(Assigneeが未割り当てのもの)を見つけてみるのもいいでしょう。
でも、「修正できそうなバグ」より「修正したいバグ」のほうがモチベーションが上がりますよね？
実際、筆者も「このバグが残ってると自分が困る」というものを(Swift JIRAで報告してから)自分で直すということを繰り返し、結果的にPR数が増えていきました。
(余談)初めてのPR
筆者の初めてのPRは「Modify "docs/ABI/Mangling.rst"」というもので、バグ修正でもなんでもありませんでした。当時、SwiftのマングリンングについてのBNFをスクリプトで抜き出そうとしたところ、当該ファイルに不具合があってできませんでした。このままでは“自分が困る”ということで提出したのが、そのPRでした。“自分が困る”はすごくモチベーションになりますね。
Swiftのバグを発見するには？
Swiftのコードを書いていると、いろんなバグに出遭います。書けば書くほど出遭います。ちなみに、筆者の職業はプログラミングとは全く関係ない業界で、プログラミングはあくまで趣味なので、コードを書くのに費やす時間は20-30分/週程度ですが、気付けば40以上のバグを報告していました。もし、職業として常日頃からコードを書いている方なら、もっとバグに出遭っていることでしょう。
というわけで、Swiftのバグを発見するには単純に「コードをいっぱい書くこと」が大事というところでしょうか。ただ、傾向としてはmacOS以外のプラットフォームのほうがバグが見逃されやすいと思われるので(あくまで経験則)、よりバグを見つけるためにはmacOS以外のプラットフォームでも動作するようにコードを書いていくのが良いでしょう。macOS以外のプラットフォームの場合、バグではなく未実装ということもあり得ますが、それはそれでPRのチャンスです。
まとめ
Commit Accessへの道は
Swiftのコードをいっぱい書く → バグをいっぱい報告する → バグを直す → Pull Requestをオープン → マージされる → We're all happy!
ということでした。
Swiftのコードをいっぱい書こう！(結論)