每个人都可以为 OpenXLA 做贡献，我们非常重视每个人的贡献。您可以通过多种方式贡献内容，包括：
在 OpenXLA 的讨论论坛上回答问题 (openxla-compose)
改进或扩展 OpenXLA 的文档
为 OpenXLA 的代码库贡献代码
以上述任意方式为基于 OpenXLA 构建的更广泛的库生态系统做贡献
OpenXLA 项目遵循 Google 的开源社区准则。
准备工作
签署贡献者许可协议
您为此项目做出的贡献必须附带贡献者许可协议 (CLA)。您（或您的雇主）保留您贡献的内容的版权；这只是授权我们使用和再分发您贡献的内容作为项目的一部分。
如果您或您当前雇主已经签署 Google CLA（即使是针对其他项目），您可能不需要再次签署。
如需查看现有协议或签署新协议，请访问 <https://cla.developers.google.com/>。
查看行为准则
此项目遵循 Tensorflow 的行为准则。
贡献流程
开发者指南
如需了解如何为 OpenXLA 设置开发环境（包括获取代码、构建环境、运行测试和提交更改），请参阅开发者指南。
代码标准
编码样式：我们遵循 Google 的代码样式指南。具体请参阅 C/C++ 和 Python 指南。提交的所有代码都必须严格遵守这些样式指南。
紧凑变更：我们遵循 Google 的工程做法。特别是，请遵守有关编写紧凑更改的指南。这样做可以大大提高合并代码的速度，因为这有助于提高可审核性，并降低更改产生意外副作用的可能性。即使您进行了大幅更改，也可以采取许多策略将其分解为更多增量更改。
测试覆盖范围：所有更改都应包含适当的单元测试。单元测试不应依赖于特定硬件（CPU、GPU 等）时序，而应随意使用模拟和虚构测试，以实现确定性和集中性测试。如果希望扩展当前难以测试的现有代码，则应对可测试性进行适当的改进。
所有更改都应在更改标题中包括适当的基准结果，以确保清楚了解其优势。
如果不确定代码中的惯例，最好检查现有代码并尝试遵循 OpenXLA 中已有的模式。
审核流程
所有提交内容（包括项目成员提交的内容）都需要经过审核。为此，我们使用 GitHub 拉取请求。如需详细了解如何使用拉取请求，请参阅 GitHub 帮助。
代码必须符合上述所有标准才能经过审核。这并非可选步骤，在申请审核之前，提交者务必要确保其代码符合要求，以确保及时接受更改。
必须通过所有测试。如果您发现测试已损坏，并且问题与构建环境或其他更改无关，请与维护者联系。
在审核过程中尽量避免范围蔓延。这是提交者和审核者的责任。如果某项更改开始变得过大，请考虑将其拆分为多项更改。
在合并变更之前，系统会进行内部测试，测试使用 Google 和其他硬件供应商的内部代码。如果我们的公共 CI 无法捕获内部测试中的失败情况，这可能会增加审核流程的额外步骤。负责审核您的更改的 Google 员工会传达所有内部测试失败情况，并说明需要修复的问题。
常见问题解答 (FAQ)
“这项基础设施变更与我的公关无关。我为什么要这么做？”
XLA 团队没有专门的基础架构团队，因此我们必须构建帮助程序库并避免技术债务。我们将它视为对 XLA 的常规更改，希望所有人都能参与进来。我们通常会在编写代码时根据需要构建基础架构。
XLA 审核人员可能会要求您与您编写的 PR 一起构建一些基础架构（或以其他方式对 PR 进行重大更改）。此请求可能看起来没有必要，或者与您尝试所做的更改无关。这可能是因为你对需要构建多少基础架构的预期与审核者的预期不一致。
如果出现预期不一致的情况，也没关系！当您刚开始接触项目时，这属于正常现象（我们有时甚至会出现这种情况）。您可能对过去完成的项目有着不同的预期。这也是在意料之中的事情！这并不意味着其中任一项目采用了错误的方法，它们只是不同而已。我们邀请您提出基础架构请求以及其他所有审核意见，并借此机会了解我们对此项目的期望。
“我以后可以处理你的评论吗？”
关于 PR 中的基础架构请求（或其他大型请求）的一个常见问题是，是必须在原始 PR 中进行相应更改，还是可以在未来的 PR 中进行后续更改。
一般来说，XLA 不允许 PR 作者通过跟进 PR 处理评价评论。当审核者确定需要在特定 PR 中解决问题时，我们通常希望作者在该 PR 中解决问题，即使请求是一项重大更改。本标准既适用于 Google 内部，也适用于外部。
XLA 采用这种方法的原因如下：
信任：赢得评价者的信任是关键所在。在开源项目中，贡献者可以随意显示或隐藏。我们批准 PR 后，审核人员就无法确保任何承诺的后续跟进行动都能真正完成。
对其他开发者的影响：如果您曾发送 PR 涉及 XLA 的特定部分，其他人很有可能正在关注相同的部分。如果我们接受您的 PR 中的技术债务，则查看此文件的每个人都将受到此债务的影响，直到提交跟进邮件为止。
审核人员的带宽：将更改推迟到后续跟进工作会对本已超负荷的审核人员产生多次成本。在等待后续跟进时，审核人员可能会忘记第一位 PR 的内容，这使得下一次审核变得更加困难。此外，审核人员还必须跟踪预期的后续跟进，确保后续跟进情况的实际执行。如果可以进行更改，使其与原始 PR 真正正交，以便其他审核者可以对其进行审核，带宽就不是问题了。根据我们的经验，这种情况很少出现。