OpenXLA には誰でも貢献できます。Google では、すべての人の貢献を高く評価しています。コントリビューションには、次のような方法があります。
OpenXLA のディスカッション フォーラムでの質問への回答（openxla-discuss）
OpenXLA のドキュメントの改善または拡張
OpenXLA のコードベースへの貢献
OpenXLA 上に構築されたライブラリの幅広いエコシステムに貢献する（上記のいずれかの方法による）
OpenXLA プロジェクトは、Google のオープンソース コミュニティ ガイドラインに準拠しています。
始める前に
コントリビューター ライセンス契約に署名する
このプロジェクトへのコントリビューションには、コントリビューター ライセンス契約（CLA）を付随させる必要があります。参加者（またはあなたの雇用主）は参加者の貢献に対する著作権を保持します。これは、参加者の貢献をプロジェクトの一部として使用および再配布する許可を Google が与えることのみを意味します。
ご自身または現在の雇用主がすでに Google CLA に署名している場合は（別のプロジェクトのものであっても）、おそらく再度署名する必要はありません。
現在の契約を確認するか、新しい契約に署名するには、<https://cla.developers.google.com/> にアクセスしてください。
行動規範を確認する
このプロジェクトは Tensorflow の行動規範に準拠しています。
寄付のプロセス
デベロッパー ガイド
コードの取得、ビルド、テストの実行、変更の送信など、OpenXLA の開発環境のセットアップ方法については、デベロッパー ガイドをご覧ください。
コード標準
コーディング スタイル: Google のコードスタイル ガイドに従います。具体的には、C/C++ と Python のガイドをご覧ください。送信されるすべてのコードは、これらのスタイルガイドに厳密に準拠している必要があります。
コンパクトな変更: Google のエンジニアリング プラクティスに従っています。特に、コンパクトな変更の作成に関するガイドをご覧ください。これにより、レビュー可能性が向上し、変更による意図しない副作用が生じる可能性が低減するため、コードをマージする速度が大幅に向上します。大規模な変更であっても、分割して増分変更を行う方法は数多くあります。
テスト カバレッジ: すべての変更に適切な単体テストを含める必要があります。単体テストは、特定のハードウェア（CPU、GPU など）のタイミングに依存せず、モックとフェイクを十分に活用して、決定論的な焦点を絞ったテストを行う必要があります。現在テストが難しい既存のコードを拡張するための変更では、テストのしやすさを適切に改善する必要があります。
メリットが明確に理解されるように、すべての変更には、適切なベンチマーク結果と変更のタイトルを含める必要があります。
コード内の規則について疑問がある場合は、既存のコードを調べ、OpenXLA ですでに使用されているパターンに従うようにすることをおすすめします。
審査プロセス
プロジェクト メンバーによる提出物を含め、すべての提出物は審査が必要です。この目的のために GitHub の pull リクエストを使用します。pull リクエストの使用について詳しくは、GitHub ヘルプをご覧ください。
コードは、審査前に上記のすべての基準に従う必要があります。これは任意です。変更がタイムリーに承認されるよう、提出者は審査をリクエストする前にコードが準拠していることを確認することが重要です。
すべてのテストに合格する必要があります。テストが破損しており、問題がビルド環境やその他の変更とは無関係であることがわかった場合は、メンテナンス担当者にご連絡ください。
レビュー プロセス中は、スコープを変更しないようにしてください。これは、報告者と審査担当者の両方の責任です。変更が大きくなり始めた場合は、複数の変更に分割することを検討してください。
変更を統合する前に、Google と他のハードウェア ベンダーの内部コードを使用する内部テストが実施されます。これにより、公開 CI で捕捉できない内部テストが失敗した場合に、レビュー プロセスに手順が追加される可能性があります。変更を審査する Google 社員が内部テストの不合格を通知し、修正が必要な点を記述します。
よくある質問（FAQ）
「このインフラストラクチャの変更は、私の PR とは関係ありません。なぜですか？」
XLA チームには専任のインフラストラクチャ チームがないため、ヘルパー ライブラリを構築し、技術的負担を回避するかどうかは全員次第です。これは XLA の変更では定期的に行われており、誰もが参加することが期待されています。通常、コードを記述する際は、必要に応じてインフラストラクチャを構築します。
XLA レビュー担当者から、作成した PR とともにインフラストラクチャを構築する（または PR に大規模な変更を加える）ように求められることがあります。このリクエストは、不必要であるか、行おうとしている変更とは無関係に見えるかもしれません。原因としては、構築する必要があるインフラストラクチャの量に関する想定と、レビュー担当者の期待値が一致していないことが考えられます。
期待値の不一致は問題ありません。これはプロジェクトを初めて行う場合には想定されたことですが過去に携わったプロジェクトによって期待される内容は異なります。これも想定どおりです。これは、どちらかのプロジェクトのアプローチが間違っているという意味ではなく、プロジェクトはそれぞれ異なります。他のすべてのレビュー コメントとともに、このプロジェクトに対する Google が期待する内容を知る良い機会として、インフラのリクエストを受け付けてください。
「今後の PR で、お客様のご意見に対応できますか？」
PR のインフラストラクチャ リクエスト（またはその他の大規模なリクエスト）に関してよく聞かれる質問は、元の PR で変更を行う必要があるかどうか、または将来の PR でフォローアップとして行うことができるかどうかです。
一般に XLA では、PR 作成者はフォローアップ PR でレビュー コメントに対処できません。レビュアーが特定の PR で対処する必要があると判断した場合、リクエストの内容が大きい変更であっても、作成者は通常、その PR で対処することを求めます。この基準は Google の外部と内部にも適用されます
XLA がこのアプローチを採用する理由はいくつかあります。
信頼: クチコミ投稿者の信頼を獲得することは、重要な要素です。オープンソース プロジェクトでは、コントリビューターの表示と非表示を自由に選べます。Google が PR を承認した後、約束したフォローアップが実際に行われたかどうかを審査担当者は確認できません。
他のデベロッパーへの影響: XLA の特定の部分に触れている PR を送信した場合、他の人が同じ部分を見ている可能性が高くなります。Google が PR で技術的負債を受け入れる場合、フォローアップが送信されるまで、このファイルを閲覧しているすべての人がこの負債の影響を受けます。
レビュー担当者の帯域幅: フォローアップへの変更を延期すると、すでに過負荷になっているレビュー担当者に複数のコストがかかります。審査担当者はフォローアップを待つ間に最初の PR の内容を忘れてしまうため、次の審査が難しくなります。また、審査担当者は予想されるフォローアップを追跡し、実際に行われたことを確認する必要があります。他のレビュアーが確認できるように、変更が元の PR と完全に直交するように変更できれば、帯域幅の問題はあまり発生しません。Google の経験上、このようなケースはめったにありません。