🪐

OSSに貢献するときの心得

に公開
OSS
idea

私はOSSのアプリ/ライブラリの開発運営（オーナー）をしています[1]。世界中の多くの人がIssueを立ててくれたりPull Requestを立てて貢献（Contribute）してくれて嬉しい一方で、初コントリビュートでやり方を知らなかったり、我流が過ぎる方がおりオーナーとしてハンドリングに困ることも多々あります。そこで、OSSに貢献するときの基本的な心得を紹介します。

Issue編

IssueはPull Requestに比べて手軽にできる貢献の第一歩です。そのため大手のOSSだと膨大な量になりがちなので質の低いIssueは一生ハンドリングされないか時効が来たら閉じられてしまいます。質の良いIssueでアピールしましょう。

全般

すでに同様の報告がないか確認しましょう。IssueとPull Requestでキーワード検索したり、リポジトリ内検索をかけて、関連するものがあれば引用しましょう。過去に検討済みでCloseになっている件も多々あります。

バグ報告

  • 問題が起きるバージョンを明記しましょう。
  • 問題が起きる環境を明記しましょう。
  • 問題の再現手順を書きましょう。必要ならスクリーンショットもあると非常にありがたいです。
  • 試したことを書きましょう。
    • コンピューターの再起動
    • ソフトウェアの再起動
    • ソフトウェアのアンインストール
  • エラーログがある場合は添えましょう。

新機能提案

  • なぜその新機能が必要なのか明記しましょう。
  • 個人的な利益に留まらず、多くの人にとって利益のある提案か俯瞰しましょう。
  • 新たな利益と増えるメンテナンスコストのバランスが取れているかを考えましょう。
  • 可能であれば実現の目処がつきやすいように前例や具体的な手法を記載しましょう。

Pull Request編

Pull Requestは直接ソースコードに対する貢献の手段で、ものにより大小はありますが、OSSのオーナーからすればこれほどありがたいものはありません。難度は高いかもしれませんがソースコードを読むことで学べることも多いです。ぜひチャレンジしてみましょう。

全般

  • 既存のコード文化から逸脱しないようにしましょう。
    • インデントスタイルを揃えましょう。
    • 既存の命名規則に従いましょう。
      • 単語を省略するかしないか
      • 品詞の語順
      • キャメルケース、スネークケース、ケバブケースのどれか
      • URLやIDなど頭字語の記法（URL or Url）
    • コメントの書き方を揃えましょう。
    • ファイルの分け方を揃えましょう。
  • 複数のコンテキストを１つのPull Requestに含めないようにしましょう。オーナーはコンテキストごとに採用するかどうかを判断したいです。
  • なるべく差分が小さくなるようにしましょう。差分が多いとレビューコストが上がりますし、他のPRやメインの開発ブランチとコンフリクトしやすいです。
  • 結果的に管理不要なファイルが増える場合は.gitignoreにそのファイルを追記しましょう。
  • READMEに明記すべき仕様の変更や追加が伴う場合はREADMEも更新しましょう。
  • レビューコメントへの対応は基本的に１レビューにつき１コミットにしましょう。レビューコメントにコミットログを紐づけて返信し、対応したことを示しましょう。コミットするだけでは、オーナーは貢献者の作業が完了したのか判断する術がありません。多くの場合PRが腐ります。

バグ修正

  • 対症療法よりは原因療法を目指しましょう。
    • とくに経験則によるマジックナンバーでの回避は最後の手段です。
  • 単なるリファクタリングは（したくなる気持ちはわかりますが）控えめにし、バグの修正に集中しましょう。
    • バグの修正にあたってリファクタリングが必要な場合は前提として別PRに切り出し、直列したPRにしましょう。
  • すでにテストが構築されている場合はテストケースを追加しましょう。

新機能追加

  • なぜその新機能が必要なのか明記しましょう。
  • 個人的な利益に留まらず、多くの人にとって利益のある提案か俯瞰しましょう。
  • 新たな利益と増えるメンテナンスコストのバランスが取れているかを考えましょう。
  • UIに変化がある場合は、スクリーンショットを添えましょう。ビルドの手間が省けると嬉しいです。
  • デプロイ先環境（例えばアプリストア）に配信できるAPIのみを利用しているか確認しましょう。
  • 複数OSやプラットフォームで提供されているソフトウェアの場合、検証可能なすべてのプラットフォームで動くように実装し、そのことを確認しましょう。
  • すでにテストが構築されている場合はテストケースを追加しましょう。

おわりに

OSSへの貢献は勇気が必要ですし、マージしてもらうにはオーナーとの粘り強いコミュニケーションが必要な場合もあります。その分、学びも大きいですし達成感はひとしおです。基本的には自分がオーナーだったらと立場を想像すれば、どんな貢献が嬉しいかはわかると思います。面倒なことも多いですが、上に挙げたような工夫を重ねるほどマージ率は上がると思いますので、努力義務としてみんなで頑張っていきましょう💪

脚注

  1. RunCat365 (Star 9.5k)、OpenMultitouchSupport (Star 209) ↩︎

Discussion