注意
此页面已弃用。请参阅PyTorch Wiki上的贡献指南。
PyTorch 贡献指南¶
PyTorch 是一个用于构建深度神经网络的GPU加速Python张量计算包，它采用基于磁带的自动求导系统。
贡献流程¶
PyTorch 组织由 PyTorch 治理 管理，贡献的技术指南可以在 CONTRIBUTING.md 中找到。
PyTorch的开发过程涉及核心开发团队与社区之间的大量开放讨论。
PyTorch 的操作方式与大多数 GitHub 上的开源项目类似。 然而，如果你之前从未参与过开源项目的贡献， 以下是基本流程。
确定你要做什么。 大多数开源贡献来自于人们解决自己的需求。然而，如果你不知道你想做什么，或者只是想更多地了解这个项目，这里有一些建议来帮助你找到合适的任务：
确定更改的范围并在GitHub问题上寻求设计评论，如果它很大。 大多数拉取请求都很小；在这种情况下，不需要让我们知道你想要做什么，直接开始即可。但如果更改将会很大，通常最好先通过提交RFC来获得一些设计评论。
一些功能添加是非常标准化的；例如，很多人会向PyTorch中添加新的操作符或优化器。在这些情况下，设计讨论主要集中在“我们是否需要这个操作符/优化器？” 提供其实用性的证据，例如，在同行评审的论文中的使用情况，或其他框架中是否存在，这在论证时会有所帮助。
从最近发布的研究中添加操作符/算法 通常不被接受，除非有压倒性的证据表明 这项新发表的工作具有突破性成果，并最终将成为该领域的标准。如果你不确定你的方法属于哪一类， 在实现PR之前先打开一个issue。
核心更改和重构可能相当难以协调，因为PyTorch主分支的开发速度非常快。对于基础或跨领域的更改，请务必与我们联系；我们通常可以提供指导，关于如何将这些更改分阶段进行，以便更容易审查。
动手编写代码吧！
请参阅 CONTRIBUTING.md 文件，以获取有关以技术形式使用 PyTorch 的建议。
打开一个拉取请求。
如果你还没有准备好让拉取请求被审查，可以先创建一个草稿拉取请求 - 之后你可以通过点击“准备审查”按钮将其转换为完整的PR。在它仍然是草稿时，你也可以在PR标题前加上“[WIP]”（“正在进行中”）。我们在进行审查时会忽略草稿PR。如果你正在处理一个复杂的更改，最好从草稿开始，因为你需要花时间查看CI结果以确认事情是否按预期进行。
为你的更改找到合适的审阅者。我们有一些人会定期检查PR队列并尝试审查所有内容，但如果你碰巧知道哪个子系统的维护者受到你的补丁影响，可以直接在拉取请求中包含他们。你可以了解更多关于 可能审查你代码的相关人员 。
在拉取请求被接受之前不断迭代！
我们将尽最大努力减少审核往返次数，并且仅在存在重大问题时阻止PR。对于拉取请求中最常见的问题，请查看常见错误。
一旦拉取请求被接受并且CI通过，你就无需再做任何事情；我们会为你合并PR。
入门¶
提出新功能¶
新的功能想法最好在特定的问题中讨论。请尽可能多地提供信息、任何相关数据以及你提议的解决方案。PyTorch团队和社区会经常查看他们认为可以提供帮助的新问题和评论。如果你对自己的解决方案有信心，可以直接去实现它。
实现功能或修复错误¶
如果你想解决一个特定的问题，最好在该问题下评论你的意图。然而，除非我们之前与开发者合作过，否则我们不会锁定或分配问题。最好是就问题展开讨论并讨论你提议的解决方案。PyTorch团队可以提供指导，从而节省你的时间。
标记为first-new-issue、低优先级或中等优先级的问题提供了最佳的切入点，是开始的好地方。
添加教程¶
许多关于 pytorch.org 的教程都来自社区本身，我们欢迎更多的贡献。 如需了解如何贡献新的教程，您可以在这里了解更多： GitHub上的PyTorch.org教程贡献指南
参与在线讨论¶
您可以在PyTorch 讨论论坛上找到用户的活跃讨论，以及在 PyTorch 开发者讨论论坛 上找到开发者和维护者的讨论。
提交拉取请求以修复开放问题¶
您可以查看所有开放问题的列表 这里。在问题上发表评论是引起团队注意的好方法。从这里您可以分享您的想法以及您计划如何解决问题。
对于更具挑战性的问题，团队将提供反馈和指导，说明如何最好地解决这些问题。
如果你无法自行解决问题，评论并分享你是否能够重现该问题可以帮助团队识别问题区域。
查看开放的拉取请求¶
我们感谢您帮助审阅和评论拉取请求。我们的团队努力保持开放的拉取请求数量在可管理的范围内，如果需要更多信息，我们会迅速响应，并且我们会合并我们认为有用的PR。然而，由于高度的兴趣，更多的目光关注拉取请求总是受到欢迎。
为代码库添加测试用例以使其更加健壮¶
额外的测试覆盖率是值得赞赏的。
推广PyTorch¶
您在项目、研究论文、文章、博客或互联网上的普遍讨论中使用PyTorch，有助于提高PyTorch及其不断壮大的社区的知名度。如果您需要市场营销支持，请联系 marketing@pytorch.org。
问题分类¶
如果您认为某个问题可以从特定的标签或复杂程度中受益，请在该问题下评论并分享您的意见。如果您觉得某个问题没有被正确分类，请评论并告知团队。
关于开源开发¶
如果你是第一次为开源项目做贡献，开发过程中的一些方面可能会让你觉得有些不寻常。
无法“认领”问题。 人们通常希望在决定处理某个问题时“认领”它，以确保当其他人最终处理它时不会浪费工作。这在开源中并不太奏效，因为某人可能会决定做某事，但最终没有时间去做。你可以提供咨询性的信息，但在最后，我们将采取运行中的代码和大致共识来快速推进。
新功能的门槛很高。与企业环境不同，在企业环境中，编写代码的人隐含地“拥有”它，并且可以期望在代码的生命周期内对其进行维护，一旦一个拉取请求被合并到一个开源项目中，它立即成为项目所有维护者的集体责任。当我们合并代码时，我们是在说，作为维护者，我们可以审查后续的更改并对代码进行错误修复。这自然会导致更高的贡献标准。
常见错误及避免方法¶
你添加了测试吗？（或者如果更改难以测试，你是否描述了如何测试你的更改？）
我们要求进行测试有几个原因：
帮助我们判断以后是否破坏了它
帮助我们判断补丁是否一开始就正确 （是的，我们确实审查过它，但正如Knuth所说，“小心以下代码，因为我没有运行它，只是证明它是正确的”）
什么时候可以不添加测试？有时一个更改可能不方便进行测试，或者这个更改是如此明显正确（并且不太可能出错），以至于可以不对其进行测试。相反，如果一个更改看起来很可能（或已知很可能）会意外出错，那么花时间制定一个测试策略就显得非常重要。
你的PR太长了吗？
对于我们来说，审查和合并小的PR（Pull Request）更容易。审查PR的难度会随着其大小非线性地增加。
什么时候可以提交一个大型的PR？如果在问题中有一个相应的设计讨论，并且得到了将要审查你代码差异的人的同意，这会非常有帮助。我们也可以提供关于如何将一个大的更改拆分成可单独发布的部分的建议。同样地，如果有对PR内容的完整描述也会很有帮助：如果我们知道里面的内容，审查代码会更容易！
对细微之处的注释？ 在代码行为复杂的情况下，请添加额外的注释和文档，以便我们更好地理解您的代码意图。
你添加了一个临时解决方案吗？ 有时，正确的答案就是一个临时解决方案。但通常情况下，我们需要讨论一下。
你想接触一个非常核心的组件吗？为了防止重大回归，触及核心组件的拉取请求会受到额外的审查。在进行重大更改之前，请确保你已经与团队讨论了你的更改。
想要添加新功能吗？ 如果您想添加新功能，请在相关问题上发表您的意图。我们的团队会尽力对社区提供反馈和评论。在构建新功能之前，最好与团队和其他社区成员进行公开讨论。这有助于我们了解您正在做什么，并增加合并的可能性。
你是否修改了与PR无关的代码？ 为了便于代码审查， 请只在你的拉取请求中包含与你的更改直接相关的文件。
常见问题¶
我如何作为评审员做出贡献？ 如果社区开发者重现问题、尝试新功能或以其他方式帮助我们识别或排除问题，这将带来很大的价值。在任务或拉取请求中评论您的环境详细信息是很有帮助的，并且会受到赞赏。
CI测试失败，这意味着什么？ 可能你的PR是基于一个损坏的主分支？你可以尝试将你的更改重新基于最新的主分支。你也可以在 https://hud.pytorch.org/ 查看当前主分支的CI状态。
哪些是最高的风险更改？ 任何涉及构建配置的内容都是一个高风险区域。除非你事先与团队讨论过，否则请避免更改这些内容。
嘿，我的分支上出现了一个提交，这是怎么回事？ 有时，其他社区成员会为你的拉取请求或分支提供补丁或修复。这通常是为了让CI测试通过。
关于文档¶
Python 文档¶
PyTorch文档是从Python源代码使用 Sphinx生成的。生成的HTML被 复制到主分支中的docs文件夹 pytorch.github.io, 并通过GitHub页面提供服务。
C++ 文档¶
对于C++代码，我们使用Doxygen生成内容文件。C++文档在一台专用服务器上构建，生成的文件被复制到 https://github.com/pytorch/cppdocs 仓库，并通过GitHub页面提供服务。
教程¶
PyTorch教程是用于帮助理解如何使用PyTorch完成特定任务或理解更全面概念的文档。 教程是使用 Sphinx-Gallery 从可执行的Python源文件或从restructured-text（rst）文件构建的。
教程构建概览¶
对于教程，拉取请求会触发整个站点的重建，使用CircleCI测试更改的效果。此构建被分成9个工作构建，总共需要大约40分钟。同时，我们使用make html-noplot进行Netlify构建，这会在不渲染笔记本输出的情况下快速构建站点以供审查。
在PR被接受后，网站将使用GitHub Actions进行重建和部署。