Good First Issue から OSS へコントリビュートしてみた

概要

TIG DXチームの多賀です。Good First Issue から、OSS (go-swagger) にコントリビュートしてみたので、経験談について記載してみます。

Good First Issue とは

Good First Issue は、GitHub の good first issue ラベルの付いた Issue を一覧で参照できるサイトです。 good first issue ラベルとは、GitHub のデフォルトで定義されており、初めてのコントリビュートに向いている Issue につけられるラベルです。

サイトは、コードレビューツールを開発されている deepsource 社によって、運営されています。対象のGitHub リポジトリは、deepsourcelabs/good-first-issue にて、コントリビュートしやすくするための条件をクリアしたものだけが管理されています。
(PRを送ることで、リポジトリを追加することも歓迎されていそうです。)

OSS コントリビュート

今回のコントリビュートの経緯としては、フューチャーOSS推進タスクフォースの活動があります。活動の一環として、OSS コントリビュートを増やしていければと考えています。筆者も少しお手伝いする中で、まずは自分がやってみようと思ったことがきっかけです。

以下は、筆者のコントリビュートまでの流れを、失敗も含めて経験談としてそのまま記載しています。少々冗長になってますが、流れがイメージできると良いかなと思ったので、そのままにしています。

Issue をみつけるまで

筆者は、OSS コントリビュートを普段から息をするようにしているタイプではないので、どうやったら簡単にできるのか調べながら実施しました。コントリビュートの方法は色々あると思いますが、筆者は GitHub の Issue を探す方法を取りました。そこからさらに調べてみた結果、初心者向けラベルがついた Issue を選べばよいのかなというところまでたどり着きましたが、実際に対象 Issue を決めかねていました。そんな中、以下の流れで Issue を決めることができました。

Good First Issue で go-swagger を発見
- GitHub の Issue からのラベル絞り込みを試していましたが、対象も多くイマイチ決めきれていないところで、Good First Issue を見つけました。good first issue を言語別に検索できるということで、得意な Go 言語で絞り込んでみました。その結果、たまたま PJ 等でよく利用していた go-swaggeer が上位に出てきました。ライブラリの利用時にコードもある程度読んで、なんとなく理解していたので、これならわかるかもと思い Issue をいくつか見てみました。
解決したいIssue を発見
- いくつか Issue を参照した中で、ひとつの Issue (Can’t configure content type in generated client · Issue #1924 · go-swagger/go-swagger )が目に留まりました。 Issue の詳細を読んでいく中で、「そういえば以前使った際に、生成された Client コードが使いづらかったな」ということを思い出し、 この機能欲しいな と思っていました。また、Issue をよく見ると good first issue がついているだけあって、作者から直しの方針がコードベースで記載されていて、後はこのコードを入れ込むだけでした。これなら、自分でもできると思い対応してみることにしました。

Issue を見つけて PR を送るまで

対象 Issue を決めたので、修正範囲を特定するために、まずはリポジトリを clone してみました。ソースコードを眺めて print デバッグしながら修正箇所を特定していきました。詳細は本筋とずれるので割愛しますが、今回は以下2点の修正でした。

Client テンプレートファイルの修正
swagger コマンドに含まれるテンプレートファイルの更新
- go-swagger では kevinburke/go-bindata を利用して、build 時にテンプレートファイルを含めるようになっていました (余談: Go 1.16 から変わるかもですね。)

修正して動作確認がとれたので、 master ブランチに commit しました。このままだと PR が送れないと気づいたので自分の GitHub アカウントに Fork して、remote を追加して Git push しました。
PR を送ろうかと考えていたとき、 go-swagger のコントリビュート方針があるのではと気づいたので、リポジトリを探してみると、.github ディレクトリ以下に、 CONTRIBUTING.md がありました。CONTRIBUTING.md にリンクされる形で、 Guidelines to maintainers を見つけました。

ガイドを読んでいると、Guidelines to maintainers に、PR の Rule があり、 Draft PR を上げてレビュー前に CI チェックしても良いとあったので、テスト修正対象の特定をしたく、ひとまず Draft PR を作ってみました。すると、テスト以外の CI が失敗していました。失敗した CI とガイドを再度見返すと「sign off」を commit へ入れてくれと記載があることに気づきました。CI のエラーメッセージを参考にしつつ commit を amend して直してみたところ、おそらく rebase で HEAD から戻すコミット数をミスしており、commit の状態が壊れてしまいました (ここは未だに細かくわかっていないです)。

commit の状態を復元するのに時間を使うか、修正箇所が少ないので最初からやり直すか悩んだ末、最初からやり直すことにしました。Draft PR を Closeし、Fork した master ブランチを汚していたので一度削除して再 Fork しました。今度は master からブランチを切り、修正を sign off 付きで commit して、再度 Draft PR を上げました。説明は fixs #${issue 番号} を入れてほしいと合ったので、Draft なこともあり、一旦その文言のみをいれて PR を発行しました。

あとで、説明を追加すればよいかと思い、1日程度置いていると、レビュアの方から Approve されてました。レビュアの方から「どうして Draft なのか ?」と聞かれていたので、「CIを見たかったから」と返しつつ Approve 出ているので良いだろうと思い、そのまま Open にしました。
また 1日後にみると、マージされていて、無事コントリビュートに成功しました。

振り返り

実際にコントリビュートしてみて、いくつか気づきがありました。

Issue 選定

コントリビュート初心者が選ぶ Issue として、個人的にですが以下2点が重要だと感じました。

「利用したことがあるライブラリ/ツール」であること
Issue を見たときに「この機能欲しい/直したい」と思えること

最初にコントリビュートするにあたって、「初めての壁」はどうしてもあります。壁突破の1つのやり方として、うまくモチベーション作る方法があるかなと思います。
この2点をクリアすることで、いい感じのモチベーションが生まれたなと思いました。

実際の手順に落とし込むと、以下の形が良さそうです。

Good First Issue 等のサイトを利用して、初心者でもできる Issue のみを参照
書きたい or 得意な言語を選定
利用したことがあるライブラリ/ツールがないか検索
Issue をいくつか眺めてみて、欲しい/直したいと最も思えるものを選択

改善点

3点ほど失敗していたので、どうしたら良かったのかについても考えてみました。

CONTRIBUTING.md を最初に読む
ガイドの読み込み不足で、いくつかミスをしました。Good First Issue のリポジトリは CONTRIBUTING.md が必ずあるようなので、まず読んで見るべきでした。
master ブランチに直修正しない
Fork 先へ push するので問題ないかと思い master にしてましたが、Fork 元の master の状態がなくなり修正が効かなくなるので、ブランチは何かしら切ったほうが良さそうでした。その際、ブランチの切り方にルールがないかガイドを確認するべきですね。
Draft PR でも参照されるので説明を書く
レビュアにもよりそうですが、Draft でも見られることがあるので、多少なりとも説明は書いておいたほうがより通りやすくなりそうです。
今回は Issue 側に細かく書いてあったので、なくてもなんとかなったのかなと思いました。

所感

OSS コントリビュートしてみた経験談について記載してみました。

開発初心者みたいな恥ずかしい失敗もしてしまいましたが、結果マージまでされてよかったです。1回経験すると、2回目以降のハードルが下がったなと実感もしているので、またコントリビュートしていきたいと思いますし、輪を広げていけると良いなと思います。