ランサーズエンジニアブログへようこそ！
初めまして、バックエンドエンジニアの磯野(@wadakatu)です。

皆さんは、OSSコントリビュートしてますか？
既に何回もやってる人、怖いのでやってない人など様々だと思います。

自分は、後者でした。
何すれば良いかわからないし、怖そうだからやらない人でした。

でも全然そんなことないんです！！

今回は、私が業務中に取り組んだOSSコントリビュート（バグ修正）の流れを共有します。
この記事を読んだ後に、「な〜んだ、OSSコントリビュートって怖くないじゃん、私もやってみよ」と思っていただければ幸いです。

本編に入る前に、これだけは覚えてほしいことがあります。

コードを書くだけがOSSコントリビュートではない

今回、私はコードを書いていますが、もちろんコードを書く以外にも色んな形で貢献することが可能です。

ドキュメントのTypo修正
英語ドキュメントの日本語翻訳
バグ・機能追加のissue, Discussionを起票

私も最初は、laravel-langのリポジトリで英語の日本語訳からOSSコントリビュートを始めました。

https://github.com/Laravel-Lang/lang/pull/2217/files

それでは、OSSコントリビュートの流れについて見ていきましょう！

第1話バグとの邂逅

今年の9月に私はあるプロジェクトに新規アサインされました。
そのプロジェクトのバックエンドはLaravelで構築されていました。

しかし、コードフォーマッターを全く活用しておらず、各エンジニアが好き勝手に自分のエディタの設定に任せて、コード整形を行なっていました。
そこで、私は「Laravelを使っているのだから、Laravel/Pintを導入してコードフォーマットを統一しよう！」と考えました。

Laravel/Pintをインストールして、いざ実行！

すると、ただコード整形を行うだけのはずが、エラーを吐いているではありませんか。。

これは何かがおかしいと思い、とりあえずコードを確認しました。
しかし、以下のようになんの変哲もない普通のコードでした。

<?php

namespace App\Models;

class User extends Authenticatable
{
  use Notifiable,
      CongratulationTrait,
      ScoreObservable,
      NotificationObservable,
      SoftDeletes,
      CascadeSoftDeletes,
      Concerns\QueryScopes,
      Concerns\CachedUserQuery
  ;

 /** 中略 **/
}

これが私とバグの出会いでした。。

第2話最新バージョンにアップデート

めちゃくちゃ焦りました。
でも焦っていても何も始まりません。

まずは、心を落ち着けてLaravel/Pintのバージョンを最新にアップデートにすることにしました。
遭遇したバグが最新バージョンだと治っていることはよくあることです。

さぁ、最新にアップデートしたし、これで治ってくれよと念じながら再度実行しました。

＼(^o^)／バグ再登場！

恐れていた事態が起こりました。
これで修正されていれば、簡単に済んだことでしょうが、そうはいきませんでした。

ここで諦めて、他の誰かがバグ修正してくれることを祈っても良かったのですが、幸いランサーズ社内では「もくもく会」という毎日午前11:00~午前12:00を自己研鑽に充てる時間があります。

なので、この「もくもく会」の時間を使ってバグ修正してOSSコントリビュートしようと決心しました！

第3話 Githubのissue or Discussion 確認

バグ修正を進めるにあたって、まずは別の人が同じバグを踏んでいないかの調査を始めました。
他の人が同じバグを踏んでいて、修正に向けて動き出していることはよくあることです。

また、自分で修正したはいいけど、実はその１時間前に他の人が修正した内容がマージされてたなんてことがあったら、悲しくなってしまうので。。

Laravel/Pintは、PHP-CS-Fixerに依存しているので、今回はその２つのライブラリのissueとDiscussionを確認しました。

しかし、関連するissue / Discussionは発見できず。。

第4話バグ原因ライブラリ特定

幸い、今回のバグは誰もまだ気づいていないバグだったようです。
それなら、私が治しましょう！

まずは、バグの原因となっているライブラリを特定しないと話になりません。
「原因？そんなのLaravel/Pintを実行して出たバグだから、Laravel/Pintが原因に決まってるじゃないか！」と思ったそこの貴方！

少し待ってください。

OSSライブラリというのは、他のライブラリに依存していることがほとんどです。
今回のLaravel/Pintは、PHP-CS-Fixerに依存しているパッケージです。
そのため、他のライブラリに原因がある可能性も考える必要があります。

今回は、まさにそのパターンでした。
そうです。PHP-CS-Fixer側にバグの原因があったのです。

第5話コントリビュートルール確認

他の誰も修正していないようで、原因のライブラリも特定したので、早速バグ修正を進めたい気持ちは理解できます。
しかし、一旦深呼吸でもして落ち着きましょう。

各リポジトリには、コントリビュートをするにあたって、抑えるべきルールが存在しています。
円滑なコントリビュートのためにも、まずはこのルールを確認しましょう。
ルールに従わないと、コード修正が受け入れられなかったり、メンテナンスの手間が増えたりする可能性があります。

OSSコントリビュートも人間関係同様に礼儀正しさが求められます。

大抵のリポジトリには、以下の名称でルールが記載されたファイルが置いてあります。

CONTRIBUTING.md
README.md
CODE_OF_CONDUCT.md

もちろんPHP-CS-FixerにもCONTRIBUTING.mdが用意されていたので、３、４回読みました。

PHP-CS-Fixerのバグ修正ルールを要約すると以下のような感じです。

失敗するテストを書いて、バグを証明してね
失敗したテストが成功するように、バグを修正してね
失敗テスト追加とバグ修正のコミットはちゃんと分けてね

第6話 issue or Discussion起票

リポジトリのルールを把握した後は、issue or Discussionにバグの詳細を記載しましょう。

一番最初に言いましたが、コードを書くだけがコントリビュートではありません。
issue や Discussionの記載も立派なOSSコントリビュートです。

将来同じバグを踏んだ人が、貴方が書いたissueを見つけてすぐに問題を解決できる可能性もあります。
これは他人を助けるチャンスでもあります。
さあ、issueを投稿しましょう！

今回、私は書いてません。ごめんなさい…

第7話 PR提出（失敗テスト作成）

それでは、PHP-CS-Fixerのルールに則って、バグ修正を進めていきましょう。
まずは、失敗するテストを書いて、そのバグが本当にバグであることを証明しましょう。
口で何度も「バグが起きてるんです！」と説明するより、1個の失敗テストを書いた方が効果的です。

今回の場合は、テスト自体は共通化されていたので、失敗するテストケースを追加しました。
実際に書いたテストケースは以下の通りです。

https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/pull/7289/commits/6da695a458ea57af722ccdfe40997055403e1533

無事テストが失敗したことを確認して、次に進みます。

https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/actions/runs/6154077966/job/16701763134

第8話 PR提出（バグ修正）

テストが失敗したので、次はそのテストが成功するようにバグを修正していきましょう。

ここが最も時間のかかるところだと思います。
ある程度成熟したOSSプロジェクトの場合、かなりコード量が多いのでバグの原因を特定するだけでも時間がかかります。

自分で問題箇所を見つけられない場合は、issueやDiscussionを通じてリポジトリの仕様に詳しい人に相談するのも良い方法です。

私が今回修正したコードは以下の通りです。
今回はかなり単純で助かりました。。

https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/pull/7289/commits/5df838a0709fc704c8d9b6c0b5678ea0d03e7e00

そして、先ほど失敗したCIが無事成功することを祈って修正コードをプッシュしましょう。
無事テストが全て成功すればOKです。

第9話アプルーブGET

無事テストが通った後は、レビュワーからのコメント・アプルーブを待ちましょう。

コメントが来た場合は、真摯に対応してしっかり反応するようにしましょう。
あまり長いことコメントを放置していると、せっかく作ったPRがクローズされかねません。

アプルーブをいただけた場合は、万歳です！
おめでとうございます！
アプルーブをいただいた時の喜びは、何事にも変え難いものがあります。。

第10話本番リリース

アプルーブいただいた後は、本番リリースを待つのみです。

大抵のライブラリはセマンティックバージョニングを採用しており、バグ修正などがすぐ本番リリースされることは基本ありません。（よっぽどクリティカルなバグでない限り）
また、リリースサイクルもリポジトリ毎に決まっていたりするので、本番リリースまで待ち時間が発生することが普通です。
ソワソワしながら、本番リリースを待ちましょう。

私も、1日に何度もGithubのページを何度も訪問して、自分のバグ修正を含んだ本番リリースはまだかなとソワソワしていたのを思い出します。。

無事本番リリースされた後に、ライブラリをアップデートしてもう一度Laravel/Pintを実行すると、ちゃんとバグが治っていました。
自分が直したので当たり前なんですけど、やっぱり実際に直面していたバグが治った瞬間というのは脳汁ドバドバ出ます。

＼(^o^)／やった！嬉しい！

最後に

以上が、私が実際に経験したOSSコントリビュート（バグ修正）の流れです。
この流れは、他のOSSコントリビュート方式（typo修正など）でもほとんど同じだと思います。

OSSへのコントリビュートは最初は怖いかもしれませんが、実際に取り組んでみると非常に充実感を感じることができます。バグに立ち向かい、コミュニティに貢献することは、スキルの向上にもつながります。そして、OSSコントリビューターとしての誇りを感じることでしょう。

もし、OSSコントリビュートを検討しているなら、怖がらずに挑戦してみてください。最初は迷子になることもあるかもしれませんが、一歩踏み出すことで新しい世界が広がり、素晴らしい経験が待っています。

一緒にOSSコントリビュートやっていきましょう！

最後まで読んでいただきありがとうございました。

怖くないよ、OSSコントリビュート

コードを書くだけがOSSコントリビュートではない

第1話 バグとの邂逅

第2話 最新バージョンにアップデート

＼(^o^)／ バグ再登場！

第3話 Githubのissue or Discussion 確認

第4話 バグ原因ライブラリ特定

第5話 コントリビュートルール確認