コントリビュータガイドのこのセクションは、損失関数の追加、テストカバレッジの改善、主要な設計変更のための RFC を作成などの貢献をはじめるのに役立ちます。TensorFlow の改善にご協力いただき、ありがとうございます。
はじめる前に
TensorFlow プロジェクトにソースコードを提供する前に、プロジェクトの GitHub リポジトリにあるCONTRIBUTING.md
ファイルを確認してください。例として、コアの TensorFlow リポジトリの CONTRIBUTING.md ファイルをご覧ください。すべてのコードコントリビュータは、コントリビュータライセンス契約(CLA)に署名する必要があります。
作業の重複を避けるために、重要な機能の作業を開始する前に最新または提案中の RFC を確認し、TensorFlow フォーラムの開発者に連絡してください(developers@tensorflow.org)。私たちは新しい機能の追加についてやや選択的であるため、既知の問題の解決に貢献いただくことでプロジェクトを支援していただくよう、お願いしています。
新しいコントリビュータのための issue
新しいコントリビュータには、TensorFlow コードベースへの最初の貢献を検索するときに、次のタグを探すことをお勧めします。新しいコントリビュータには最初に「good first issue」および「contributions welcome」プロジェクトに取り組むことを強くお勧めします。 このようなプロジェクトに取り組むことによりコントリビュータは、貢献ワークフローに慣れ、作業の中心となる開発者が新しいコントリビュータに慣れることができます。
大規模な問題や新機能への取り組みを支援するチームの採用に関心がある場合は、developers@ group にメールでお問い合わせください。また、RFC の最新リストをご確認ください。
コードレビュー
新機能、バグ修正、およびコードベースに対するその他の変更は、コードレビューの対象となります。
プルリクエストとしてプロジェクトに貢献されたコードのレビュー作業は、TensorFlow 開発の重要なコンポーネントです。そのため、ほかの開発者が提出したコードをレビューすることをお勧めしています。特にその機能を使用する可能性が高いのであれば、尚更です。
コードレビューでは、以下の点を検討してください。
これを TensorFlow に含めるべきでしょうか? 使用される可能性が高いと考えられますか? TensorFlow ユーザーとして、この変更を気に入って使用しますか? この変更は TensorFlow の範囲内ですか? 新しい機能を維持するためのコストは、そのメリットに値するでしょうか?
コードは TensorFlow API と一貫性がありますか?パブリック関数、クラス、およびパラメータは適切な名前で直感的に設計されていますか?
ドキュメントは含まれていますか?すべてのパブリック関数、クラス、パラメータ、戻り値の型、および格納された属性は、TensorFlow の規則に従って名付けられ、明確に文書化されていますか?新しい機能は TensorFlow のドキュメントに記載されていますか?可能な場合は例が示されていますか?ドキュメントは適切にレンダリングされますか?
コードは人間が読めるように書かれていますか?冗長性は低いですか?変数名は、明確性または一貫性のために改善する必要がありますか?コメントを追加する必要がありますか?役に立たない、または無関係なコメントを削除する必要がありますか?
コードは効率的ですか?より効率的に実行するために簡単に書き換えることはできますか?
コードは以前のバージョンの TensorFlow と下位互換性がありますか?
新しいコードは他のライブラリに新しい依存関係を追加しますか?
テストとテストカバレッジの改善
高品質な単体テストは、TensorFlow 開発プロセスにとって非常に重要です。そのために、Docker イメージが使用されます。 テスト関数に適切な名前が付けられていること、アルゴリズムの有効性やコードのさまざまなオプションをチェックします。
すべての新機能とバグ修正には、適切なテストカバレッジが含まれている必要があります。また、新しいテストケースの貢献や既存のテストの改善も歓迎します。現時点でバグが発生していない場合でも、既存のテストが完了していないことが判明した場合は、問題を報告し、可能であればプルリクエストを送信してください。
各 TensorFlow プロジェクトのテスト手順の具体的な詳細については、GitHub のプロジェクトリポジトリにあるREADME.md
とCONTRIBUTING.md
ファイルをご覧ください。
十分なテストを実行する上で特に注意する点:
- すべてのパブリック関数とクラスがテストされていますか?
- パラメータの妥当性、それらの値、値のタイプ、および組み合わせがテストされていますか?
- テストではコードが正しいことが検証されていますか?また、コードはドキュメントに記載されているとおりのことを実行しますか?**
- 変更がバグ修正の場合、非回帰テストが含まれていますか?
- テストは継続的インテグレーションに合格しますか?
- コードのすべての行がテストされていますか?そうでない場合、例外は合理的かつ明示的ですか?
問題を見つけた場合は、コントリビュータがそれらの問題を理解して解決できるように支援してください。
エラーメッセージまたはログの改善
エラーメッセージやログを改善するための貢献を歓迎します。
貢献ワークフロー
コードの貢献(バグ修正、新しい開発、テストの改善)はすべて、GitHub 中心のワークフローに従います。TensorFlow 開発に参加するには、GitHub アカウントを設定し、以下を行います。
作業する予定のリポジトリをフォークします。プロジェクトリポジトリページに移動し、[フォーク]ボタンを選択します。自分のユーザー名の下にリポジトリのコピーが作成されます。(リポジトリをフォークする方法の詳細については、このガイドをご覧ください。)
リポジトリをローカルシステムにクローンします。
$ git clone git@github.com:your-user-name/project-name.git
作業を保持する新しいブランチを作成します。
$ git checkout -b new-branch-name
新しいコードを記述し、テストを作成して実行します。
変更をコミットします。
$ git add -A
$ git commit -m "commit message here"
変更を GitHub リポジトリにプッシュします。
$ git push origin branch-name
プルリクエスト(PR)を開きます。GitHub の元のプロジェクトリポジトリに移動します。最近プッシュされたブランチに関するメッセージが表示され、プルリクエストを開くかどうかが聞かれます。プロンプトに従い、リポジトリ間で比較して、PR を送信します。コミッターにメールが送信されます。周知させるためにメーリングリストにメールを送信することをお勧めします(詳細については、「 PR に関する GitHub ガイド」をご覧ください。
メンテナや他のコントリビュータがあなたの PR をレビューします。会話に参加して、必要な変更を追加してください。PR が承認されると、コードがマージされます。
次の貢献に取り組む前に、ローカルリポジトリが最新であることを確認してください。
上流をリモートに設定します。(これを行う必要があるのは、プロジェクトごとに 1 回だけです。毎回行う必要はありません。)
$ git remote add upstream git@github.com:tensorflow/project-repo-name
ローカルマスターブランチに切り替えます。
$ git checkout master
上流から変更をプルダウンします。
$ git pull upstream master
変更を GitHub アカウントにプッシュします。(オプションですが、良い習慣です。)
$ git push origin master
新しい作業を開始する場合は、新しいブランチを作成します。
$ git checkout -b branch-name
追加の git
および GitHub リソース:
コントリビュータチェックリスト
- 貢献ガイドラインを読む
- 行動規範を読む
- コントリビュータライセンス契約(CLA)に署名したことを確認する
- 変更がガイドラインに準拠しているかどうかを確認する
- 変更がTensorFlowコーディングスタイルと一致しているかどうかを確認する
- ユニットテストを実行する