こんにちはとるめんです。
この記事はグロービスアドベントカレンダー2021の20日目の記事です。
先日は@maKunugiさんのグロースハックに関するお話でした。
この記事ではOSSへの貢献について考えていることを書きます。
概要
最近Log4jの脆弱性等でOSSが話題になりましたね。普段お世話になっているライブラリへの貢献を意識した方も多いのではないでしょうか。ですが「キッカケがない..」「難しそう...」といった理由でまだ一歩踏み出していない方もいると思います。
私自身も凄腕エンジニアではありませんし、バリバリ貢献しているわけではないのですが、多少はOSSに貢献した経験があるので自分なりに意識していることについて書こうと思います。
貢献へのきっかけ
OSS貢献してみたいけどどこから初めていいかわからないという方が多いと思います。私がオススメするのは業務で使っているOSSから始める方法です。
業務では使っているOSSのドキュメントを読んだりテストを見る機会が多いです。その中でtypoを見つけたら直してしまいましょう。他の人がコード読む時のスピードがもしかしたら早くなるかもしれませんし、翻訳にかけやすくなったりするかも知れません。
業務で使っているOSSにテストが足りないと思ったら足してもらう提案もいいと思います。1 将来業務で言語やフレームワークをアップデートする時に絶対に役に立ちます。
実際にコードを修正したりするための時間やレポジトリへの理解がない場合はissueをたてるのもいいでしょう。
業務ではエッジケースが発生することが多く、OSSに追加して欲しい機能というのが出てきやすいです。ぜひ自分の使っているライブラリには変更や修正が提案できるんだという意識をもってみてください。
実際に貢献する時考えること
READMEを読む
これが一番大事です。必要な情報はだいたいのってます。
貢献に対する具体的な方法はCONTRIBUTINGという見出しや別ファイルで記載されていることが多いです。
過去issueを見る
過去のissueを見るとレポジトリの空気感がわかります。自分は主に以下の観点で見ています。
自分の考えている問題と同じような既存のissueやPRはないか？
既に同じ内容のissueやPRがあるならついてるコメント等全部読んだりして解決しているのかわざと解決していないのか確認します。同じ内容のissueを乱立されてもメンテナーの方は困ってしまいます。過去バージョンに対して同じ内容でissueが立っているのを見つけた場合は「現行バージョンでもこんな風に再現します」という風にコメントするのも良いと思います。
GitHub以外にissueについて議論しているフォーラム的なものはあるか？
大きめなOSSだとGitHub以外にメールフォーム等議論の場が存在する場合があります。それを認識しないで提案やissueを行うと色々すっ飛ばし兼ねないので確認しておくと良いでしょう。
Ruby on Railsなんかはセキュリティに関する問題は別口で起案してほしいと明記されてますね。2
問題の再現スクリプトはどんなふうに書かれているのか？
バグでも機能追加でも現状のコードの動作を説明する必要があると思います。その際に再現スクリプトがあるとメンテナの方が確認しやすいです。他のissue立てている人のスクリプトを参考にすると分かりやすいスクリプトになり、良いissueやPRになると思います。
closeされているissueはどんな理由でcloseされているのか？
closeされているissueもチラ見すると良いと思います。コメント等からメンテナの方の方針がわかります。
どんなCIを行っているのか？
CIの内容もレポジトリにより様々なので見ておくと良いでしょう。コードの修正をするときに気にかけるべき内容がわかります。依存ライブラリのバージョンを複数検証していたり独自のドキュメント精査を行っていたり色々あります。
issueやPRのテンプレート的なものはあるか？
issueやPRを試しに立てようとしてみてテンプレートの内容を確認するのもオススメです。提案内容を説明する文章を考える時の骨子になってくれます。
コミットメッセージはどのように書かれているか?
コミットメッセージに独自のルールがあったりするレポジトリもあるので確認すると良いでしょう。特になさそうだったらWhyを意識する通常のコミットメッセージでも問題ないと思います。
PRにはコードやテスト以外に含めるべきものはあるか？
変更と一緒にCHANGELOGも追記する必要があるレポジトリもあります。他の方のPRを見てコードやテストの修正以外にも変更しているファイルがあるか確認すると良いでしょう。
メンテナーの方がコードにどんな指摘をしているのか？
とっても大事ですね。多めのコメントがついてるPRをみたりすると良いでしょう。
issueやPRのコメントをちゃんと書く
僕も完全にできているわけではないんですが、以下のようなことを気をつけると良いんじゃないかと思います。
自分が報告している問題はちゃんと説明する。再現スクリプトを書いたりコードの実行結果を記載する
過去issueを見る、でも書きましたが、問題をコードで説明できていると分かりやすいPRになります。コード以外にも参照リンクを貼ったり等色々できることはあると思います。
issueには自分が使用しているライブラリのバージョンを記載する
これも検証しやすくなるのでおすすめです。
既存issueを治すPRならちゃんとfix #xxxとつける
大事ですね。
最後に
これ以外にもこんなこと見てるよ！考えてるよ！という人がいたらぜひコメントで教えて下さい！
また、ここまで色々書いてきましたが、PRやissueをやたらめったらたてることが良いことではありません。メンテナーとしても自分が管理しているコードに他人のコードをいれるのは色々リスクがあります。
以下はRubyコミュニティでのOSS関するリンクですが、参考になると思います。
- https://github.com/rails/rails/pull/13771#issuecomment-32746700
- https://speakerdeck.com/knu/ossdejie-guo-wochu-sufang-fa