初めてOSSにプルリク送って感じたこと

経緯

npxコマンドでNuxt.js + Vuetifyのプロジェクトテンプレートが簡単に作れるのだけど、初期テンプレートにあるVuetifyのロゴの解像度が低くてぼやけているのが気になって、「これなら自分でも直せそうだな」と思ったので修正してみることにした。

はじめてのプルリク

仕事では相談してわからないことをアドバイスしてもらったりされたことはあるが、プルリクを送ってコードレビューをしてもらった経験はない。

とりあえずリポジトリをフォークして、Qiitaの記事とか過去のクローズされたプルリクのやり取りとか見ながら、ブランチ切って・コード修正・テスト修正・コミット・プッシュして、見様見真似でプルリクを送った。
qiita.com

拒否されたらどうしようとか、これであってるのかなとか結構不安だったが、2度のレビューの後無事マージされた。

学び

  • 知らないツールに触れた
    AVAなんてテストフレームワーク知らなかったし、commitlintなんてものがあるなんて知らなかった。自分が触れることのないツールを使う機会を得て学びになった。

  • レビュワーの人の英語がいいなと思った

Can we change the file name more readable?
ファイル名をわかりやすく(リーダブルに)変えることはできないだろうか?

Can you ~ ? ではなく、 Can we ~ ? としていて主語を「あなた」ではなく「私たち」としている部分に、OSSってこういうことなんだなぁと感じさせられた。

blog.cybozu.io

issue/PRの発行には、いくつかコツがあります。第一にプロジェクトの中の多くの人が嬉しくなることをアピールしましょう。たとえば単に「このバグが直らないと弊社のシステムが止まるんです!」とみなさんの都合をまくしたてるよりも、コミュニティの中のみんなが遭遇しうる問題だという言い方のほうが反応してもらえる可能性が高いでしょう。

この記事の中にも書かれているように、自分の視点だけではなくコミュニティにとって良いことかという視点が重要なんだなと気付かされました。 普段何気なく打っている、npm installとかcomposer installとかが動くのは誰かがメンテしてくれているおかげなんですよね。