OSSコントリビュータのススメ

OSS コントリビュートのメリット

簡単に OSS コントリビュートするメリットをまとめてみました。

1. マージされたら愛着が湧く
2. マージされたらいい気分になる
3. 他のエンジニアに自慢ができる 👺
4. PR したときに、レビューがもらえる可能性がある
5. 他人（つよつよエンジニア）のコードが見れて勉強になる
6. github プロフィールの「Organizations」に OSS のアイコンが載る可能性がある

メリットは上げたらきりがなさそうですね。
どうでしょうか。みなさんも挑戦したくなったのではないでしょうか？😎

具体的なやり方

それではここから具体的な方法を記載していきます。

環境構築

まず環境構築（ローカル環境で動作する状態まで）です。

今回は、私が挑戦した Vuetify をベースに進めていきます。
基本的な OSS コントリビュートの流れは以下の図のような形になります。

▼ コントリビュートの流れ

通常の開発と異なる点としては、Forkをしている点です。
Fork の詳細に関しては記事の趣旨とずれるため割愛します 🙏（参照したい方: Fork について）

ローカルにクローンする

Fork してきたリポジトリを、git cloneでリモート環境に保存します。

git clone [email protected]:{githubのアカウント名}/vuetify.git

公式の案内に沿って環境構築をする

今回参考にしている Vuetify は、公式ドキュメントにローカル環境の立ち上げ方法が記載されています。
こちらを参考に進めていきます。

# vuetify フォルダに移動
cd vuetify

# すべてのプロジェクト依存関係をインストール
yarn

# ERRが出る場合
npm install -g node-gyp

# パッケージをビルド
yarn build

# devフォルダに移動
cd packages/vuetify/dev

# develop立ち上げ
yarn dev

あとは、http://localhost:8080 にアクセスすると真っ白い画面が開きます。
packages/vuetify/dev/Playgroud.vueを書き換えてもらえると反映されます。

issue の探し方

環境構築ができたら、Vuetify の issue ページで探していきます。

闇雲に issue を一つ一つ見ていってもいいのですが、Vuetify はありがたいことに初心者コントリビュータ向けにgood first issueというLabelを用意してくれています。
good first issue以外にもT:bugも内容によっては簡単なものが多い気がします。

ちなみに私が挑戦した issue は、VMenu,good first issue,T: bugのラベルがついているものでした。

issue の中身覗いてもらうと、詳細が記入されています。
issue によってはすでに原因が究明できていて、あとは直すだけという状態のものも存在します。
そのため、issue 内でコメントがある場合、がんばってやり取りを追ってもらえると「ここを修正すればいいのか。」というヒントが得られます。

この issue をやる！キミにきめた！
となったら issue 内で決意表明をすることをオススメします。
人気の OSS だと、他のコントリビューターとバッティングすることがあるため、assign を明示的に示しておくことで余計なコミュニケーションコストを回避することができます。

また issue は全文英語ですが、毛嫌いせず読んでいきましょう。
僕は友達の DeepL 君に翻訳してもらいました。

ローカルで再現してみる

issue を見ると、事象を再現できるようコードが用意されている場合があります。
その場合は、コピペでpackages/vuetify/dev/Playgroud.vueに貼り付けて事象を再現します。

ローカルで反映が完了したら、バグの特定に移ります。

修正が完了したら・・・

とりあえず、お疲れさまでした。
あとは、PR を作成するだけです。

Vuetify の PR は日本語ではなく英語で記載します。
翻訳君を利用しながら作成していきましょう。

すでにテンプレートは用意されているため、PR を作成すると題目が反映されます。
テンプレートをベースに直近に取り込まれた PR のコメントを参考に作成してもらうと良いかと思います。

現在（2022 年 9 月）テンプレートの題目は以下の６つで構成されています。

1. Description

今回 PR した内容の全体説明です。対応した issue を貼っている方や細かく修正した内容を記述したりやり方は様々です。

2. Motivation and Context

日本語に訳すと「動機と背景」です。修正しないと何が起こるのかを記述している方が多いです。

3. How Has This Been Tested?

再現方法です。codepen のリンクを貼ったり、どういった環境で起こったかを記述します。

4. Markup

How Has This Been Tested?の環境かつ、実際に再現できたコードを記述します。

5. Types of changes

すべてで４つの項目があり、今回の変更がどの項目に該当するかチェック入れれば OK です。

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement/refactoring (non-breaking change that doesn't add any features but makes things better)

6. Checklist

今回の変更の最終チェック項目になります。（親切ですよね）
PR のタイトルは 64 文字いないか、コードルールに沿っているかなどがあります。

• The PR title is no longer than 64 characters.
• The PR is submitted to the correct branch (master for bug fixes and documentation updates, dev for new features and backwards compatible changes and next for non-backwards compatible changes).
• My code follows the code style of this project.
• I've added relevant changes to the documentation (applies to new features and breaking changes in core library)

６項目を確認したら PR しましょう！

merge されるまでの流れ

PR を送った後は、CI のチェックやレビュアーからのコードレビューがあります。
また、リポジトリによっては、CLA(contributor license agreement) への同意が求められることがあります。その場合は bot などによって手順がコメントされるので、そちらに従って同意しましょう。

PR の内容に問題がなければそのまま merge されますが、レビュアーから request changes や suggestion などを受けることがあります。
コードをより良くするための意見なので、その場合もビビらず、真摯に対応しましょう。

全てのチェックが完了すると、管理者によって merge されます。
私の場合は、特に戻しなどなく 1 週間ほどで merge していただけました。

最後に

いかがだったでしょうか！
ぜひ自分の成長のためにも OSS コントリビュート挑戦してみてください！

採用情報

現在エンジニア募集しています！

▼ 採用ページ