OSSにpull requestを出した時の流れ

これまでOSSに対してパッチを送るということを、実質したことが無かった。
ハードルが高いと感じていたからだ。たとえば、英語でコミュニケーションが取れるのか、プロジェクトのお作法に則れるのか、そもそも送ったパッチがしょぼいかもといった不安だ。

GW中暇だったので、重い腰を上げ、GitHubのpull requestの形でパッチを送ってみた。
https://github.com/VSCodeVim/Vim/pull/2618

その時の流れを示してみる。
OSSにパッチを送ってみたいけど躊躇していたり、何を送ったら良いか分からない人の参考になれば。

どんなパッチを送るか考える

普段良く使うツールやライブラリで欲しい機能や解決して欲しい不具合に考える。
↓
VSCodeのVim Extensionで、コマンド入力時に/キーで過去の履歴を選択できないことが不便に感じていた。
なので、それに対処することに決定。

誰かが既に取り組んでいないか確認

GitHubのissueを適当なキーワードで検索
↓
以下のissueが見つかる。
https://github.com/VSCodeVim/Vim/issues/779
https://github.com/Microsoft/vscode/issues/426
↓
取り組もうとはした人はいるものの、VSCodeがExtention向けに公開しているAPIの仕様の都合上、単純には実現できなさそう。

代替案を考える

vimには、「q:」コマンドというものがある。
コマンド履歴を表示して、その中から選択したコマンドを実行するというもの。
コマンド入力欄の/キーで履歴を選択するよりは不便だが、ないよりはましだと思うので、「q:」コマンドを実装することにした。

プロジェクトの情報を収集する

パッチを送る時のルール(Contributing)、ソフトの大まかな作りのドキュメントを読む。

手を動かす

VSCodeVimのリポジトリをforkする。仕事でGitHubを使用するときはforkしないので、forkする理由はよく分からなかったが、リポジトリ本体にするpush権限がないからだろう。fork後は、普通にコードを修正してローカルでコミット。

forkしたリポジトリの扱いや、コミットメッセージの書き方は以下のページが参考になった。
https://qiita.com/itosho/items/9565c6ad2ffc24c09364
https://qiita.com/icb54615/items/3544c419a3f6fc3534fb

pull requestを出して、修正の取り込みを依頼する

1. 動作確認
2. テストコードの実行(プロジェクトのルール)
3. 手動による動作確認(UIに影響があり かつ テストコードでテストできないので)
4. push
5. issueの登録
   プロジェクトのルールでissueの登録が推奨されていたので(手を動かす前に登録した方が良いかも)
6. pull requestを出す
   オリジナルのリポジトリではなくforkで作ったリポジトリから

後は、reviewerの反応を待つ。

レビュー指摘対応

reviewerがコメントをくれるので、それに沿ってコードを修正したり、議論したり。

mergeされたことの確認

全部の指摘に対応すると、reviewerがmasterにmergeしてくれる。
リポジトリのpull requestの状態を確認して、mergeされたことを確認したら、終了。
issueを自分でcloseすべきかは判断できず(本来、fix という形式でコミットメッセージを記述しておくと、自動でcloseしてくれるらしいが)

pull request出してみた感想など

一言でいえば、パッチを送るハードルはかなり低かった。

• 英語力は無くても、意外と英語でコミュニケーションは取れた。書く方はほとんどGoogle翻訳頼み。
• パッチは送っても意外と無視されなかった
• プロジェクトルールには厳密に従わなくても、特にパッチを拒否されたりはしなかった(従わないことが良いこととは思わないが)
• pull requestをmasterに取り込む直前でコミットログの整理が要求される or reviewerが整理するのかと思ったが、そんなことは無かった。自分の雑然としたコミットログがそのままmasterに取り込まれてしまい、恥ずかしい。もう少し綺麗にコミットメッセージを書けばよかった。
• javascriptのスーパセットであるTypeScriptを触ったが、今どきのjavascriptはいけてる記述ができることが分かった。たとえば、非同期処理のPromise, async/awaitなど。
• パッチの作成中、いくつかの不具合に遭遇。普通に使っている分には手を加える余地のないものに見えたが、開発に参加してみるとパッチのネタは意外とあるものだと感じた。
• 仕事も一応、ソフト開発なので、一日中仕事している感があった。相当な気力が必要。これが続けられる人はすごい