🔰

ドキュメント修正からはじめるOSSコントリビュート【Expo編】

2025/10/07に公開

 はじめに前回の記事では、OSS コントリビュートの基本的な流れを紹介しました。

いわば「入門編」として、実際に Pull Request を出す流れを学ぶような内容です。
前回の記事はこちら👇

https://zenn.dev/kaz_z/articles/first-contributions
今回はその次のステップとして、実際の OSS である Expo に PR を出したときの体験を紹介します。

内容はドキュメント修正とそれに関連するスクリプト修正のみですが、小さな修正でも OSS に貢献できると実感できるものでした。
この記事を読んで、“これなら自分にもできそう” と思ってもらえたら嬉しいです。

 対象読者OSS コントリビュートをしてみたいが何から始めればいいかわからない方
実際のコントリビュートの流れを知りたい方

 PR を出すまでの経緯最近、React Native のフレームワークである Expo について調べる機会がありました。

Expo はオープンソースで開発されており、GitHub 上でソースコードが公開されています。
学び始めるにあたって、まずはチュートリアルに取り組むことにしました。

ただ、チュートリアルを進めていく中でドキュメントの一部がスクリプト実行後のコードと一致していないことに気づきました。
簡単に紹介すると、npx create-expo-app を実行して新しいプロジェクトを作成したあと、reset-project スクリプトを実行すると既存のファイルをリセットしてくれます。
ドキュメントには、リセット後のコードは以下のようにStyleSheet.createを使ってスタイルを定義する説明が載っていました。
index.tsx
import { Text, View, StyleSheet } from 'react-native';

export default function Index() {
  return (
    <View style={styles.container}>
      <Text>Edit app/index.tsx to edit this screen.</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    alignItems: 'center',
    justifyContent: 'center',
  },
});
しかし実際に reset-project スクリプトを実行した結果は、以下のように View コンポーネントに直接スタイルを定義するコードが生成される状態でした。
index.tsx
import { Text, View } from 'react-native';

export default function Index() {
  return (
    <View
      style={{
        flex: 1,
        justifyContent: 'center',
        alignItems: 'center',
      }}
    >
      <Text>Edit app/index.tsx to edit this screen.</Text>
    </View>
  );
}
些細な差ではありましたが、公式ドキュメントとして正確である方がいいだろうと思い、修正を提案することにしました。

 既存の Issue と PR を確認するまずは、Expo の GitHub リポジトリにアクセスし、既存の Issue や PR を確認しました。

同じような問題が報告されていないか、またはすでに修正が提案されていないかをチェックしました。
調べたところ同じ問題は報告されていなかったので、自分で修正を提案しようと考えました。

最初に Issue を立ててから PR を出すことも考えましたが、軽微な問題なので直接 PR を出すことにしました。

 CONTRIBUTING.md を読む次に、リポジトリにある CONTRIBUTING.md を読みました。

ここには、コントリビューションを行う際のガイドラインが記載されています。

各種ルールや手順を確認し、遵守することを心がけました。

 実際に PR を出してみた今回の PR は以下です。
https://github.com/expo/expo/pull/39358
レビューの返信文や、英語でのやり取りの文面づくりは ChatGPT に相談しながら進めました。

これ以降は、実際に PR を出してからマージされるまでの流れを紹介します。

 9 月 3 日 - PR を作成ドキュメントとスクリプトを修正した PR を作成しました。

Expo のリポジトリは PR の数が多いので、説明欄はテンプレートに加えてスクリーンショットを添えるなど、レビュワーが内容を把握しやすく目に留まるような工夫をしました。

 9 月 4 日 - レビューコメントがくるPR を出してから半日も経たないうちに、一人目のメンテナからレビューコメントが届きました。

内容は「テンプレートの変更は良いが、ドキュメントの変更をこの PR に含めるべきではない」というものです。

これに対して私は、自分の考えを添えたうえで「テンプレートとドキュメントを同時に修正する案（A 案）」と「PR を分ける案（B 案）」の 2 パターンを提示し、どちらが良いかを尋ねました。

 9 月 10 日 - 質問の返信がくる最初の反応が半日後だったのに対し、今度は 5 日後に二人目のメンテナから返信が来ました。

私の質問に対する回答で、B 案がいいねという内容でした。

 9 月 12 日 - 修正して再度レビューを依頼するB 案の修正を行い、再度レビューを依頼しました。

すると、二人目のメンテナからはすぐに Approved してもらいました。

一人目のメンテナからはまだ返信がなかったので、しばらく待つことにしました。

 9 月 18 日 - レビュー依頼を再リマインドする一週間経っても反応がありません。

海外はバケーションもあるし、もしかしたらちょうど休暇中なのかもしれないと思いながら様子を見ていました。

それでも気になって PR を何度か開いては閉じる日々が続き、少しそわそわしていました。

気持ちを落ち着かせるためにも、一人目のメンテナに「お時間のあるときにレビューお願いします」とコメントしました。

 9 月 19 日 - Approved されるするとコメントした翌日に反応があり、一人目のメンテナからも Approved してもらいました。

 9 月 28 日 - マージされるApproved されてからすぐにマージされるかと思いきや、なかなかマージされません。

リリースタイミングなどの都合もあるかもしれないと思いつつ、他の PR がどんどんマージされていくのを見て、自分の PR が埋もれてしまっていないか少し気になってきました。
そこで、過去半年間の PR を遡って、メンテナー以外の一般コントリビューターによる PR が Approved からマージまでにどのくらいかかっているかを調査しました。


承認からマージまでの期間
該当 PR の割合
備考


1 日以内
約 50%
半分は即日〜翌日にマージ

3 日以内
約 80%
大多数は 3 日以内にマージ

1 週間以内
約 90%
ほとんどは 1 週間でマージ完了

2 週間以上
10%未満
ごく一部。リリース都合や追加調整の可能性

調べた結果、1 週間以上かかるのはかなりレアケースであることがわかりました。

それなら一度確認しておこうと思い、「レビューありがとうございます。マージ前に私の側で対応が必要なことはありますか？」とコメントを残したところ、翌日には無事にマージされました。


最新コミットに自分がいる記念スクショ

 おわりに今回の記事では、実際の OSS に PR がマージされるまでの過程を紹介しました。

小さな修正でも誰かの役に立ち、プロジェクトの一部になれるのが OSS の魅力だと感じました。

もし「やってみたいけど少し不安」と思っている方がいたら、まずはドキュメント修正のような小さな一歩から気軽に踏み出してみるのがおすすめです。

承認からマージまでの期間	該当 PR の割合	備考
1 日以内	約 50%	半分は即日〜翌日にマージ
3 日以内	約 80%	大多数は 3 日以内にマージ
1 週間以内	約 90%	ほとんどは 1 週間でマージ完了
2 週間以上	10%未満	ごく一部。リリース都合や追加調整の可能性

GitHubで編集を提案

はじめに

対象読者

PR を出すまでの経緯

既存の Issue と PR を確認する

CONTRIBUTING.md を読む

実際に PR を出してみた

9 月 3 日 - PR を作成

9 月 4 日 - レビューコメントがくる

9 月 10 日 - 質問の返信がくる

9 月 12 日 - 修正して再度レビューを依頼する

9 月 18 日 - レビュー依頼を再リマインドする

9 月 19 日 - Approved される

9 月 28 日 - マージされる

おわりに

Discussion