> For the complete documentation index, see [llms.txt](https://jp-contents.innersourcecommons.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jp-contents.innersourcecommons.org/understanding-the-innersource-checklist/contents/5-creating-good-house-rules-for-guests-writing-contributing-agreements.md). # 来客に良いハウスルールを作る: コントリビューション協定を書く **要約** * トラステッドコミッターには、コントリビューション協定の記述を通じてコントリビューターにハウスルール\[5-1] を説明する責任があります(例えば、コード規約や依存関係等)。コントリビューション協定は生きたドキュメントです。 * コントリビューターは「良き来客」となり、コントリビューションの前にアグリーメントや他の目につくドキュメントを読む必要があります。コントリビューターが協定に沿って整ったコントリビューションをするほど、それが受け入れられるようになります。 * マネジメントはトラステッドコミッターがこれらのアグリーメントを作成することを支援する必要があります。 * アグリーメントを標準化することは、トラステッドコミッターのオーナーシップが低下することにつながるので慎重になる必要があります。複雑なアグリーメントはコントリビューションの妨げになるので、リスクの高いプロジェクトに限定されるべきです。 *** トラステッドコミッターは、壊れたコードや、適切にテストされていないコード、ドキュメントが書かれていないコード、彼らのコーディングスタイルから乖離したコードを受け入れ、オーナーシップを持たされることはできません。 コントリビューション協定は、それらの責務をコードを書いた開発者が担えるように形式化する方法なのです。 ## コントリビューション協定とは何か トラステッドコミッターは、*コントリビューション協定* を記述して所有します。 コントリビューション協定があることでハウスルールは明確になり、コードによるコントリビューションをトラステッドコミッターが受け入れるために必要なことをコントリビューターに知らせることができます。 コントリビューション協定は開発に携わるすべての人の目に触れられるものです。 アグリーメントには、トラステッドコミッターの名前や連絡先、スケジュールが記載されていなければなりません。 それ以外の内容はトラステッドコミッター次第ですが、以下の点が書かれていると良いでしょう。 * トラステッドコミッターの専門領域 * コミュニティ・ガイドライン * コーディング規約 * テスト記述の規約 * ブランチ作成の規約 * コミットメッセージの規約 * 良いプルリクエストを作成する方法 * 機能リクエストの提出方法 * 不具合報告の提出方法 * セキュリティ上の問題の報告方法 * ドキュメントの書き方 * 完了の定義 * 依存関係 * ビルドプロセスの流れ * スプリントの流れ * ロードマップ トラステッドコミッターは、プロジェクトを保護するためにこれらのアグリーメントを利用できるようにしておくことが重要です。 トラステッドコミッターは、もし他のチームによるコントリビューションが指定に従っていない場合、コントリビューション協定を参照しつつ、なぜコントリビューションが拒否されているかを説明できる必要があります。 そうすることは、社内政治や、より広範に渡る問題を最小化することに大いに役立ちます。 ## 私の家は君の家(気楽にしてね) \[5-2] コントリビューション協定は、コントリビューターの期待値を管理するためにも重要な役割を果たします。 私たちは、宿泊客にとってのハウスルール\[5-1] を比喩として使います。 全員が同じ道徳規範に従っていると思い込むのではなく、宿主が宿泊客に自らの期待値を伝えれば物事はスムーズに進みます。 壊れやすいものがたくさんあり、整理整頓されたキッチンで普段から過ごす人と、程よい生活感のある部屋や猫の引っかき傷のある家具に囲まれて生活している人とでは、異なるハウスルールを持つことになるでしょう。 そして宿主は、電子レンジと食器洗浄機を同時に動かそうとするとブレーカーが必ず落ちてしまうといったような、家の中にある予測のしづらい構造については予め客に注意を促さねばなりません。 コードに関するそのようなハウスルールや落とし穴を一覧化して配置するのに、コントリビューション協定は理想的な場所です。 そうすることで、それは明確に書かれたハウスルールのように、客が損害を被ったり、誤解をしたり、嫌な感情を覚えたりすることを未然に防ぎます。 ここまでの比喩は、コントリビューターの取るべき行動にも当てはまります。 善良な宿泊客は提示されたハウスルールに従いますし、当然のことながらルールにかかれていないことでも率先して整理整頓をするでしょう。 つまり、目についた不具合を回収したり、リファクタリングを施すこともあります。 そして *素晴らしい* 宿泊客はボトルワインを持ってきてくれることさえあるでしょう。 素晴らしいコードベースの「お客さん」は、新しい機能の開発にコントリビューションしてくれたり、誰もが待ち望んでいた修正をしてくれるかもしれません。 ## ウィン-ウィン 多くのコントリビューターは、自分の行動や成果物がコントリビューション協定により従うほど、それがより早く受け入れられコミットされると気づくでしょう。 また、より寛大なコントリビューション協定を見れば、変更を提案したり提出することのリスクはより低いとわかるでしょう。 ## 1つの解決策ですべてのサイズにフィットするか？ オープンソースの世界では、団体が異なればコントリビューションする際のルールも異なります。 違いのほとんどはリスクに関することです。 Linuxカーネルは、非常に厳しいコード提出のガイドラインや、単純なコントリビューション協定よりも遥かにプロセスを敷いています。 一方で、Node.js のモジュール開発は非常に寛大であり、プロジェクトに関わる人々には自分の作業が誰かの試みの重複になっていないかを検索を通じて確認するように求めている程度にとどまっています。 このような多様性が存在することは、ひとつの企業の中でいろいろなプロジェクトがあることと似ています。どんな企業でも、失敗すれば会社が傾いてしまうことが避けられない中核のプロジェクトがあり、そのプロジェクトには厳密なコントリビューション協定が求められます。 一方で標準化することが望まれるツールも存在し、これは比較するとかなりリスクの低い活動だと言えます。 そのツールを開発しているチームはよりシンプルなコントリビューション協定を敷き、人々がコントリビュートしてくれるように誘い出す柔軟さをもつべきでしょう。 時に、このようなリスクの低いコードベースはコントリビューターがインナーソースプロジェクトに参加する方法を学ぶのに安全な場所となるでしょう。 コントリビューションの作成では、安全性と参加しやすさのバランスが問われます。 短く簡単な協定は、コントリビューションが歓迎されていて、その過程でトラステッドコミッターたちが助言や支援をする意思があることを示すことになるでしょう。 長く、より複雑な協定はプロジェクトの難しさやリスクを伝え、そしてコードが受け入れいられるまでにコントリビューターはいくつかの関門をくぐり抜ける必要があるという事実を告げることになります。 会社全体で標準化を進めて1つのコントリビューション協定を標準化しようと試みたことのある企業も存在します。 これは大企業が無意識に取る行動としてはいたって自然なものです。 しかし、私たちはこういった企業の取組には反対してきました。 なぜなら、会社全体に適用させる協定はトラステッドコミッターからオーナーシップを取り上げることになり、企業にとっても彼らの同意を得ることが負担になるからです。 また、これまで述べてきたような柔軟性を失うことに繋がってしまうのももうひとつの理由です。 代わりに、トラステッドコミッターのための出発地点として、様々なリスク水準や複雑さに適応できるコントリビューション協定の雛形を作成します。 加えて、私たちは、振り返りの後や、新しいトラステッドコミッターが加入したタイミングなどに、コントリビューション協定を読み返し必要な更新を加えるよう、トラステッドコミッターたちに依頼しています。 コントリビューション協定は生きたドキュメントであり続けることが不可欠なのです。 ## 5章の参考文献と注釈 * \[5-1] (訳注) 一般にハウスルールとは、特定の団体や組織でのみ適用される規則を指しますが、この章では宿泊施設を比喩として持ち出し、プロジェクトのオーナーを宿主、コントリビューターを宿泊客、ハウスルールを宿泊規約と例えています。 * \[5-2] (訳注) 原文では "Mi Casa Es Su Casa" と記載されています。これは直訳すると「私の家はあなたの家」ですが、転じて「気楽にしてね」という意味で使われます。