プロジェクトがどのような種類のコントリビューションを求めているのか、ここに情報を提供してください。例えば、バグレポート、ユーザーの質問に対する回答、ドキュメントの改善、バグの修正、新機能の実装などです。
バグレポートの提出方法に関する情報をここに追加してください。これには、問題を再現し修正するためにプロジェクトがどのような情報を必要とするかについてのヒントが含まれるべきです。また、よく見られるバグのような設定ミスの情報も含めることができます。
また、初動までの時間やその後のプロセスなどに関して、コントリビューターが期待すべき情報についても記載してください。
機能リクエストを提出する方法についての情報をここに追加してください。また、初動までの時間やその後のプロセスなど、コントリビューターが期待すべき情報についても記載してください。
プロジェクトが遵守しているドキュメントのベストプラクティスや、ドキュメントの構築方法、チェック方法、プロジェクトに変更を戻す方法などの情報を含めてください。
このセクションでは、以下の情報を提供します。
プロジェクトのソースコードにアクセスする方法
プロジェクトの一般的なレイアウト
開発環境に対する要求事項
コードの書式に関するガイドライン
テストの実行方法
このセクションでは、トラステッドコミッターになるためのプロセスがコントリビューターに開かれている場合、そのプロセスを明示する必要があります。
このセクションは、既存の トラステッドコミッターへのリマインダーと、新しい トラステッドコミッターへの説明として、他のメンバーをホストチームに追加する方法について説明するものです。繰り返しになりますが、この情報は組織内のすべてのプロジェクトで同じものであることが理想的で、ここから中央の情報にリンクさせることができます。
あなたのプロジェクトのミッションについての簡潔な(3〜5行の)説明が含まれている必要があります。このセクションのゴールは、あなたが何に取り組む予定かを述べ、外部のコントリビューターがこのプロジェクトに歓迎されそうな機能の種類をおおよそ理解できるようにすることです。 Producing Open Source Software の Mission Statement Chapter も参照してください。
このセクションには、初めてプロジェクトを使う人に向けた、使い始めるための簡単な説明を記載します。さらに詳細なドキュメントにはここからリンクをさせましょう。
このセクションでは、以下のいずれか、またはすべてを列挙することができます。
ソフトウェアが対応する機能、ユースケースのリスト
トレードオフを解決するために使用される設計原理に関する情報
ユーザーレベルのドキュメントへのリンク
よくある質問(FAQ)に対する回答。できれば、特定の質問とその回答にリンクして、簡単に参照できるようにした形式が望ましいです。
このセクションには、ユーザーとしてプロジェクトのヘルプを得る方法についての簡単なドキュメントを記述します。 イシュートラッカーをユーザーに対して指し示すようにシンプルなディレクションでもかまいません。また、アーカイブされ検索可能なチャットチャネルとメーリングリスト、オンラインのユーザーフォーラムを紹介することもできます。
このセクションには、プロジェクトと連絡を取る方法に関する情報を含める必要があります。通常これにはアーカイブされた検索可能およびアクセス可能なコミュニケーションチャネルへのリンクが含まれます。
このページは、プロジェクトのトラステッドコミッターに謝意を表すのに良い場所です。 また、このプロジェクトにおいてトラステッドコミッターであることが何を意味するのかについての情報を含めるのにも良い場所です。 理想的には、組織内のすべてのプロジェクトが同じ定義を使用のが良いでしょう。その場合、すべての README が同じ定義へのリンクを貼ることになります。 このリンクを残す理由は、インナーソースのプロジェクトで働いたり貢献した経験がない、もしくは少ない同僚が、日々の仕事に必要な技術プロジェクトから会社全体の情報へのダイレクトリンクを持てるようにするためです。
このセクションでは、初めての人がコントリビュートを始めるために知っておく必要があるすべての事柄についてドキュメント化(もしくはリンクを貼る)する必要があります。 以下のトピックのすべてがカバーされることは希ですが、あなたのプロジェクトが標準的なセットアップと何が違うのか、以前のコントリビューターが理解しにくいと感じたことに重点を置いて書いてください。
ソースコードを見つける方法
プロジェクトで助けを必要としている問題のリストを見つける方法。これらの問題は、技術的・非技術的な両方の問題になりえます。通常、これらの問題は、コントリビューターがアクセスできるイシュートラッキングシステムも掲載されます。
プロジェクトのアーキテクチャ、一般的なコーディング規約、テスト規約など、さらなるドキュメントへのリンク
技術的なコンとリビューションについて、変更を加え、プロジェクトをビルドし、変更をテストする方法
変更した内容をプロジェクトにサブミットする。
理想的には、プロジェクトにとって望ましい変更プロセスがどのようなものであるかについての情報も含めてください。コントリビューターはまずイシューを作成して提案を提出すべきなのか、それともすぐにでも変更を提出することができるのか。投稿をレビューする際に重要なことは何ですか?
さらに、プロジェクトで守りたい設計の価値観についても概要を説明しておく必要があります。これらを明示することで、トレードオフをより早く、より簡単に解決できることがよくあります。さらに、暗黙の前提に対する変更を透明化するのにも役立ちます。
時間が経つにつれて、このセクションがかなり大きくなっていることに気がつくと思います。その場合は、例えば CONTRIBUTING.md と TESTING.md のように、情報を別のファイルに移動することを考えてみてください。