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