結城です。

OSSプロジェクトへのコントリビュートの「べからず集」記事について、まだ要領を掴めていない人が「自分のしようとしていることもそれにあてはまるのではないか？」と心配になってコントリビュートをためらうことがないように、具体的な例と考え方を紹介するシリーズの6本目です。前回（5回目）、前前回（4回目）、前前前回（3回目）、前前前前回（2回目）に続き、今回は「べからず」として挙げられている6つ目の点の「意義のある報告や提案をする」ということについて説明します。

6. 無意味な変更を提案しない（意義のある報告や提案をする）

このシリーズの発端になった元記事自体、Tシャツ目的のspamプルリクエストに嫌気がさした人によって書かれた物だったことから、元記事の6項目めはシンプルに「そういうspam行為をするな！」という話になっています。

そのこと自体には特に付け加えることも無いのですが、それだけだと話が終わってしまうので、ここではもう少し一般的な話に広げて、「どのような変更の提案なら、してもいいのか」「変更を提案するときは、どういう切り口で提案すればよいか」を説明することにします。

プロジェクトオーナーが「この変更を待っている」と明示している物は狙い目

OSS開発プロジェクトのイシュートラッカーを見てみると、「Good First Issue」のようなタグが付けられている例や、開発者自ら「誰かこれを実装してくれませんか？」と協力者を募っている例が見つかる場合があります。

特に提案してみたいアイデアは無いけれども、腕試しやコードへの慣熟、開発者に対する信頼の積み増しがしたい、あるいはもっと単純に、純粋に開発という行動を通じてそのプロジェクトに協力してみたい、という人は、こういったイシューから作業に取り組んでみるのがおすすめです。というのも、プロジェクトオーナーが自ら表明しているということは、これらのイシューに基づいてプルリクエストをする分には「どんな変更なら有意義か？」で悩む必要がないからです。このような場合、コードの出来に大きな問題が無ければ、すんなりマージしてもらえる可能性は高いでしょう。

やりたいことがはっきりしている場合でも、このような切り口でコントリビュートを重ねることには、プロジェクトオーナーからの信頼を積み重ねられるというメリットがあります。「この人は変な事をしない」「この人はプロジェクトの事情をよく分かってくれている」と認知してもらうことで、プロジェクトの方針自体の見直しが必要になるような大きな変更の提案でも、受け入れてもらえる可能性が出てくる場合があります。

過去のイシューから提案の採用傾向・却下傾向を見る

自分から新たにイシューを立てて、プロジェクトに対して何か提案をしてみたい、という場合でも、似たような問題を取り扱ったイシューが無いかどうか、過去の例を調べてみるのは有効です。たとえば、何か新しいファイル形式への対応を提案しようとしているなら、別のファイル形式に対応したときの提案を見ると、提案の仕方を考える上で大いに参考になります。

もし類似の事例で却下されたイシューやプルリクエストがあった場合、やりとりを見ると却下の理由が分かる場合があります。自分がこれからしようとしている提案が、そのイシューやプルリクエストの却下理由と同じ要素を含んでいるのであれば、提案内容を見直すヒントになるでしょう。やり取りの中で「こういう情報が欲しい」のような形で必要な判断材料に言及されている場合、提案時点でそれらを揃えておくと、プロジェクトオーナー側の負担が減って、提案がより採用されやすくなるかもしれません。

プロジェクトの目的やスコープ、方針を確認する

自分が提案しようとしている内容について、参考にできる過去のイシューやプルリクエストが存在しない場合には、提案内容がプロジェクトの趣旨に合致しているかどうかを自分で判断する必要があります。

プロジェクトの趣旨は一般的には、プロジェクトの公式サイトや、GitHub上のリポジトリであれば「README」ファイルで説明されていることが多いです。特に、「このプロジェクトは何々を目的としています」「このプロジェクトは何々は目的としていません」といった分かりやすい書き方でプロジェクトオーナーの意思が表明されている場合には、その内容が大いに参考になります。

そのようなはっきりした書き方がなされていない場合や、単に「このソフトウェアは何々をします」というソフトウェアの現状の説明しかなされていない場合には、周辺的な情報からプロジェクトオーナーの意志を推測する必要があります。わかりやすい判断材料の例をいくつか挙げてみます。

• 実行時のプラットフォーム（Windows、macOS、Linuxなど）や開発言語（JavaScript、Ruby、Pythonなど）、表示メッセージやドキュメントの言語（日本語、英語、中国語など）について、特定のケースの情報ばかりが多く書かれていて、他のケースへの言及がない場合、そのケースに特化することがプロジェクトの趣旨の一部である可能性がある。

  • もしそうであれば、別のケースへ対応するための変更は、趣旨にそぐわないために採用されない可能性が高い。例えば、「位置情報を扱うRubyのライブラリ」の開発プロジェクトに対して「Pythonでも使えるようにして欲しい」という要望・提案は、前提となる開発言語がそもそもマッチしないため、恐らく採用されない。

  • ただし、他言語対応のソフトウェアで表示メッセージが英語しか用意されていないようなケースでは、日本語など他の言語での表示メッセージ定義を提供する（翻訳する）変更は採用してもらえる可能性が高い。

• コミット数が多い、最初のコミットが古いなどの場合、プロジェクトの歴史が長いと判断できる。

  • もしそうであれば、プロジェクトの方針が明確に固まっているために、現行の方針から大きな変化が必要となる変更は採用されない可能性がある。

  • 逆に、プロジェクトの歴史が浅い場合には、プロジェクトの方針が固まっていないために、ドラスティックな変更でも採用される可能性がある。

• 知名度が高いソフトウェアや、多くのソフトウェアからライブラリとして使用されているソフトウェアである場合、（特に歴史が長ければ長いほど）後方互換性を重視している可能性が高い。

  • もしそうであれば、既定の挙動を変更する提案は、後方互換性を損なうため採用されない可能性が高い。

  • 新機能の提案であっても、既存の機能と著しく使い勝手が異なる機能の提案は採用されない可能性がある。

  • 提案時に、既存の機能・既定の挙動が損なわれていないことを確認する自動テストを含めておくと、プロジェクトオーナーにとっては「変更をマージして大丈夫かどうか」の判断のコストが減るため、採用される可能性が高まると考えられる。

• 動作を変えるための設定・指定について、利用者側での詳細な指定ができず、細かい部分は自動判別するようになっている場合、「設定より規約」の方針を取っている可能性がある。

  • もしそうであれば、単純に設定項目を追加する変更の提案は採用されない可能性が高い。

  • 設計方針を合わせて、必要な動作を全自動あるいは半自動で判別できるようにすると、提案を採用してもらえる可能性が高まると考えられる。

ただ、これらの例を踏まえた提案であっても採用されない場合はありますし、上記の例に当てはまらないイレギュラーな変更の提案でも、プロジェクトオーナーの判断によっては採用される可能性はあります。基本的には、提案時にはいきなり作業に取りかかるのではなく、まず「このような変更はどうか？」とプロジェクトオーナーの判断を仰ぐ所から始めるようにしましょう。

まとめ

以上、「無意味な変更を提案しない（意義のある報告や提案をする）」という原則について、実例を挙げて解説してみました。

OSS Gateでは、新型コロナウィルスの感染拡大防止の観点から、現在は東京地域を主体としたワークショップをオンライン（Discord）で開催しています。次回開催予定は12月12日（土曜）13:00からで、ビギナー（ワークショップで初めてのフィードバックを体験してみたい人）・サポーター（ビギナーにアドバイスする人）のどちらも参加者を募集中です。ご都合の付く方はぜひエントリーしてみて下さい。業務のチームのメンバーや後輩の方にOSSへのコントリビュートをしてもらいたいと思っている方は、自身をサポーターとして、メンバーや後輩の方をビギナーとして参加のお声がけをして頂くのもおすすめです。

また、当社では企業内での研修としてのOSS Gateワークショップの開催も承っています（例：アカツキさまでの事例）。会社としてOSSへの関わりを増やしていきたいとお考えの企業のご担当者さまは、お問い合わせフォームからご連絡頂けましたら幸いです。

ツイートする

フォローする