dbt-coreにおけるOSS活動ことはじめその6 ~ PRの話 ~

# 本記事が目指すこと
- dbt-coreにおけるOSS活動を始めるにあたってやるべきこと、学びになったことを紹介する
    - 複数回に渡り連載する予定
        - これまでの投稿記事
            - [dbt-coreにおけるOSS活動ことはじめ ~投稿記事まとめ~](https://qiita.com/dai_zamurai/items/e48cc3a4f52adc86ccfc)


# 注意
- 投稿時点(2023/6/30)での情報に基づくため、本記事で紹介した手順が今後も利用できる保証はありません
    - 筆者はこの手順にてPRを立ててマージされましたが、それを保証するものではありません
- なお、本記事は筆者が所属する会社と関係なく、個人の記事であることをご了承ください

# 背景
- 筆者は、ちゅらデータ株式会社に務める会社員であるが、就業時間中に職務としてのdbt-coreのOSS活動を始めた（OSS活動自体が初めての経験）
- CONTRIBUTING.mdには明示的に記載されてない部分があったため、それらの解決策を提示する

# 前提
- [前回の記事](https://qiita.com/dai_zamurai/items/9c741686dd09245fc1f8)で紹介したように、解消したいIssueを見つけた、あるいは自らIssueを立てたとする

# 本編
## PRの立て方
まずは、PR(PullRequest)の立て方について簡単に紹介する。
1. [CONTRIBUTING.md](https://github.com/dbt-labs/dbt-core/blob/main/CONTRIBUTING.md)の上位レベルのドキュメント「[Expectations for OSS contributors](https://docs.getdbt.com/community/resources/oss-expectations)」に目を通す
- 特に「Pull requests」の項について目を通すと良い。例えば、全てのPRはIssueに関連づける必要があることが述べられている。ただその例外として、ドキュメントのタイプミスなど、表面的な修正を求めてPRを開いているだけの場合は、Issueを関連づける必要ないことも明記されている
- また、ここで押さえておくべきポイントとして、ドキュメントには以下の3つが挙げられており、次のように解釈できる
    1. Test
        - PRをOpenにすると、いくつかのテストとコードチェックが実行され、テストに合格する必要がある
            - セキュリティ上の理由から、一部はメンテナの承認が必要な場合がある
            - 失敗したテストとPRをマージすることはない
            - テストが失敗する理由がわからない場合は、コミュニティに相談する
    1. Contributor License Agreement (CLA)
        - CLAに署名する必要がある
            - これにより、オープンソースdbtソフトウェアの著作権やライセンスに対する予期せぬ影響を心配することなく、コードをマージできることが保証される
    1. Changelog
        - Changieを用いて変更ログファイルをコミットする必要がある

2.dbt-labs/dbt-coreのリポジトリをフォークする
- 画面右上の[Fork]をクリックし、自分のリポジトリにフォーク
    - 参考資料
       - [GitHub Docs：リポジトリをフォークする](https://docs.github.com/ja/get-started/quickstart/fork-a-repo)

3.フォークしたリポジトリに対象コードをコミットする
- 少なくとも以下のファイルが必要
    - 加筆・修正したファイル
    - Changieを用いた変更ログファイル
        - 使い方については、過去の記事を参照のこと
            - [dbt-coreにおけるOSS活動ことはじめその4 ~ Changieを用いた変更ログ管理の話 ~](https://qiita.com/dai_zamurai/items/2eb70c39413f96e504ba)

4.dbt-labs/dbt-coreのmainブランチにマージするPRを作成する
- [dbt-labs/dbt-core][main]←[自分のアカウント/dbt-core][対象ブランチ]と指定してPRを作成する
    - 参考資料
        - [GitHub Docs：フォークからプルリクエストを作成する](https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)

5.PRの説明文を記述する
- 定められたテンプレートに従い記述する
    - resolves
        - 関連するIssueを記述する
    - Description
        - 簡潔に説明を記述する
    - Checklist
        - チェックリストの内容を確認し、すべて満たせているかをチェックする
            - これが満たせていない場合、テストやレビューがされない

6.PRをOpenにする
- 1~5の手順に従ってPRを作成しOpenにする

## PRを立てた後のコミュニケーション
次に、PRを立てた後のコミュニケーションについて紹介する。
PRを立てた後、数日立つと管理者からレビューが返ってくるのだが、これがいつレビューが返ってくるかの連絡は無いので不安になる。
そんなときには、[Expectations for OSS contributors](https://docs.getdbt.com/community/resources/oss-expectations)に書かれた以下の文章を読むことをオススメする。

> Sometimes, this can feel like shouting into the void, especially if you aren’t met with an immediate response. We promise that there are dozens (if not hundreds) of folks who will read your comment, maintainers included. It all adds up to a real difference.

要約すると、

虚空に向かって叫ぶように感じることもありますが、あなたのコメントを読む人が数十人 (数百人ではないにしても) いることを約束します

のようにドキュメントに書いてくれているので、「きっと誰かが読んでくれているはず。待ち続けよう」と辛抱強く待つことができた。忠犬ハチ公の気持ちで待つのである。


また、当然ながらコミュニケーションは英語でやりとりするため、英語が苦手な場合は、翻訳ツールを駆使してコミュニケーションを取ると良い。（筆者もそれで乗り切った）

そして何回かやりとりを重ねて、無事マージされると今日からあなたはdbt-coreにおけるOSSコミッターになれる。

追伸
参考までに、筆者がマージされたPRはこちらである。なお、本記事の投稿日(2023/6/30)にマージされた。

- https://github.com/dbt-labs/dbt-core/pull/7665

マージされたときはたまらなく嬉しかった。ぜひ御仁にも味わっていただきたい



# 終わりに
ちゅらデータでは、クレイジーな仲間を募集しているでござる
データエンジニア、もしくはSE系からデータエンジニアになりたい方がいればぜひ、御仁の力量に応じたグレード（ジュニア/ミドル/シニア）にて、応募するでござる

https://herp.careers/v1/churadata/T6Oag1FxE34V