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