PyTorch 贡献指南¶
PyTorch 是一个 GPU 加速的 Python 张量计算包，用于 使用基于 ON TAPE 的 Autograd 系统构建深度神经网络。
贡献流程¶
PyTorch 组织由 PyTorch 管理 治理和贡献技术指南 可以在 CONTRIBUTING.md 中找到。
PyTorch 开发过程涉及大量开放 核心开发团队和社区之间的讨论。
PyTorch 的运行方式与 GitHub 上的大多数开源项目类似。 但是，如果您以前从未为开源项目做出贡献， 这是基本过程。
弄清楚你要做什么。大多数打开 来源贡献来自人们挠自己的痒。 但是，如果您不知道自己想要做什么，或者只是 为了更熟悉该项目，这里有一些提示 有关如何查找适当任务的信息：
浏览问题 tracker 并查看 有任何问题您知道如何解决。问题是 由其他贡献者确认往往更适合调查。 我们还为可能存在的问题维护了一些标签 适合新人，例如 Bootcamp 和 1hr，尽管 这些标签维护得不太好。
加入我们的开发讨论，让我们知道您有兴趣 了解 PyTorch。我们非常乐意帮助研究人员和 合作伙伴可以快速掌握代码库。
弄清楚你的改变范围并伸出手进行设计 对 GitHub 问题发表评论（如果它很大）。大多数拉取 请求很小;在这种情况下，无需让我们知道是什么 你想做的，就开始吧。但是，如果更改要 large 时，获得一些关于它的设计评论通常是个好主意 首先通过提交 RFC 来获取。
一些功能添加非常标准化;例如，大量的 人们向 PyTorch 添加新的运算符或优化器。设计 这些情况下的讨论主要归结为，“我们想要这个吗 作员/优化器？为其效用提供证据，例如用途 在同行评审的论文中，或存在于其他框架中，有助于 bit 时。
通常不接受从最近发布的研究中添加运算符/算法，除非有压倒性的证据表明 这项新发表的工作具有开创性的结果，最终将 成为该领域的标准。如果您不确定您的方法属于何处， 在实施 PR 之前，请先打开一个 Issue。
核心更改和重构可能非常难以协调 因为 PyTorch master 的开发速度非常快。 一定要就根本性或横向的变化伸出援手; 我们通常可以指导如何将此类更改暂存到 更容易审查的作品。
编码出来！
CONTRIBUTING.md 有关在 技术形式。
打开拉取请求。
如果您还没有准备好审查拉取请求，请创建一个草稿 先拉取请求 - 稍后可以通过按 “准备审核”按钮。您还可以在 PR 的标题前面加上 “[WIP]”（“正在进行中”），当它仍处于草稿阶段时。我们将忽略 在执行审核通过时起草 PR。如果您正在处理复杂的更改， 最好从草稿开始，因为您需要花费 花时间查看 CI 结果，看看事情是否成功。
为您的更改找到合适的审阅者。我们有一些人 定期通过 PR 队列并尝试审查 所有内容，但如果您碰巧知道 给定受补丁影响的子系统是，请随意包含 他们直接放在拉取请求上。您可以了解有关可以审查您的代码的关注人员的更多信息。
迭代拉取请求，直到它被接受！
我们将尽最大努力减少审核往返和 仅在存在重大问题时阻止 PR。对于最常见的 issues 中，请查看 Common Mistakes。
一旦拉取请求被接受并且 CI 通过，就会有 您无需执行任何其他作;我们将为您合并 PR。
开始¶
提出新功能¶
新功能的想法最好针对特定问题进行讨论。请包括 尽可能多的信息、任何随附数据以及您的建议 溶液。PyTorch 团队和社区经常审查新问题 以及他们认为可以提供帮助的评论。如果您对 您的解决方案，请继续实施它。
报告问题¶
如果您发现了问题，请先搜索 存在的问题 回购。如果您找不到类似的问题，请创建一个新问题。 提供尽可能多的信息以重现有问题的信息 行为。此外，还包括任何其他见解，例如您的行为 期望。
实现功能或修复 Bug¶
如果您想修复特定问题，最好在 单个问题。但是，我们不会锁定或分配 问题，除非我们之前曾与开发人员合作过。 最好就这个问题展开对话并讨论您的 建议的解决方案。PyTorch 团队可以提供指导，为您节省 时间。
标记为 first-new-issue、low 或 medium 优先级的议题提供 最好的入口点是很好的起点。
添加教程¶
pytorch.org 上的大量教程都来自社区本身，我们欢迎更多贡献。 要了解有关如何贡献新教程的更多信息，您可以了解更多信息 这里： PyTorch.org 教程贡献指南 Github 的
改进文档和教程¶
我们的目标是制作高质量的文档和教程。罕见 内容包含拼写错误或错误的情况。如果你找到了一些东西，你 可以修复，请向我们发送 PR 以供考虑。
查看 文档 部分，了解我们的系统 工程。
参与在线讨论¶
您可以在 PyTorch 讨论中找到正在进行的活跃讨论 面向用户的论坛以及面向开发人员和维护人员的 PyTorch 开发论坛。
提交拉取请求以修复未解决的问题¶
您可以在此处查看所有未解决的问题的列表。对 Issue 是引起团队注意的好方法。从这里您可以 分享您的想法以及您计划如何解决问题。
对于更具挑战性的问题，团队将提供反馈和 如何最好地解决问题的方向。
如果您无法自行解决问题，请评论和分享 您是否可以重现问题对团队有所帮助 确定问题区域。
审查打开的拉取请求¶
感谢您帮助审查和评论拉取请求。我们 团队努力将打开的拉取请求数量保持在可管理范围内 尺寸，如果需要，我们会迅速回复以获取更多信息，并且 合并我们认为有用的 PR。然而，由于高水平的 对 PR 的兴趣和额外的关注总是值得赞赏的。
提高代码可读性¶
提高代码可读性对每个人都有好处。通常最好提交 少量涉及几个文件的拉取请求与大型拉取 请求，该请求涉及许多文件。在 PyTorch 中开始讨论 论坛或与 您的改进是开始的最佳方式。
添加测试用例以使代码库更健壮¶
感谢额外的测试覆盖率。
推广 PyTorch¶
您在项目、研究论文、文章、博客、 或围绕互联网的一般讨论有助于提高对 PyTorch 和我们不断壮大的社区。请联系 marketing@pytorch。org 提供营销支持。
分类问题¶
如果您认为某个问题可以从特定标签或级别中受益 的复杂程度，对问题发表评论并分享您的观点。如果你 认为问题没有正确分类，请发表评论并让团队知道。
关于开源开发¶
如果这是您第一次为开源项目做出贡献，一些 开发过程的某些方面对您来说可能看起来很不寻常。
没有办法 “索赔” 问题。人们经常想 “索取” 当他们决定处理它时，以确保没有 当其他人最终在做它时，浪费了工作。这不会 真的在开源中工作得太好了，因为有人可能决定工作 在某件事上，最终没有时间去做。随意捐赠 信息，但归根结底，我们 将需要运行代码和粗略的共识来快速前进。
新功能的门槛很高。与 在公司环境中，编写代码的人 隐式地 “拥有” 它，并且可以预期它会为 代码的生命周期，一旦拉取请求合并到打开的 源项目，它立即成为集体责任 该项目的所有维护者。当我们合并代码时，我们说 我们（维护者）可以审查后续更改，并且 对代码进行错误修复。这自然会带来更高的标准 的贡献。
要避免的常见错误¶
您是否添加了测试？（或者，如果更改很难测试，您是吗 描述一下你是如何测试你的更改的？
我们要求进行测试的原因有几个：
帮助我们判断以后是否打破它
帮助我们首先判断补丁是否正确 （是的，我们确实审查了它，但正如 Knuth 所说，“当心 遵循代码，因为我没有运行它，只是证明了它 正确”）
什么时候可以不添加测试？有时更改是不可能的 方便地测试过，或者更改是如此明显正确（并且 不太可能被打破），不测试它是可以的。在 相反，如果变化似乎是可能的（或已知是可能的） 要意外损坏，投入时间 制定测试策略。
你的 PR 太长了吗？
我们更容易审查和合并小 PR。难度 查看 PR 会随其大小非线性缩放。
什么时候可以提交大额 PR？如果有 Issue 中相应的设计讨论，从 将要审查 diff 的人。我们还可以提供帮助 就如何将大的更改拆分为单独的 可运输零件。同样，如果存在完整的 PR 内容的描述：更容易查看代码 如果我们知道里面有什么！
对微妙事物的评论？如果代码的行为 是细致入微的，请包括额外的评论和文档以允许 us 以更好地了解代码的意图。
您是否添加了 hack？有时，正确的答案是黑客攻击。但 通常，我们将不得不讨论它。
您想触摸一个非常核心的组件吗？为了防止 主要回归，触及核心组件接收的拉取请求 额外的审查。确保您已与团队讨论过您的更改 在进行重大更改之前。
想要添加新功能？如果您想添加新功能， 评论您对相关问题的意图。我们的团队努力 对社区进行评论并向社区提供反馈。最好有 之前与团队和社区的其他成员进行公开讨论 构建新功能。这有助于我们了解您的情况 正在工作，并增加它被合并的机会。
您是否接触了与 PR 无关的代码？为了帮助进行代码审查， 请只在拉取请求中包含直接 与您的更改相关。
常见问题解答¶
我如何以审阅者的身份做出贡献？如果 社区开发人员重现问题、尝试新功能，或 否则，请帮助我们识别或排查问题。评论 包含环境详细信息的任务或拉取请求很有帮助，并且 赞赏。
CI 测试失败，这意味着什么？也许你的 PR 是基于 离开一个坏掉的主人？您可以尝试将更改变基到顶部 最新的主人。您还可以查看 硕士 CI 在 https://hud.pytorch.org/。
什么是最高风险的变化？任何触及构建的东西 配置是一个有风险的区域。请避免更改这些内容，除非 您事先已经与团队进行了讨论。
嘿，我的分支上出现了一个提交，这是怎么回事？有时，其他社区成员会提供补丁或修复程序 您的拉取请求或分支。这通常是获取 CI 测试所必需的 通过。
关于文档¶
Python 文档¶
PyTorch 文档是使用 Sphinx 从 python 源生成的。生成的 HTML 为 复制到 pytorch.github.io 的 master 分支中的 docs 文件夹， 并通过 GitHub 页面提供。
C++ 文档¶
对于 C++ 代码，我们使用 Doxygen 生成内容文件。C++ 文档 构建在特殊服务器上，生成的文件被复制到 https://github.com/pytorch/cppdocs 存储库，并从 GitHub 提供 页面。
教程¶
PyTorch 教程是用于帮助理解使用 PyTorch 进行 完成特定任务或理解更全面的概念。 教程是使用 Sphinx-Gallery 从可执行的 python 源文件或重组文本 （rst） 构建的 文件。
教程 生成概述¶
对于教程，请拉取 请求会触发 使用 CircleCI 重建整个站点，以测试 改变。此构建分为 9 个 worker 构建，大约需要 40 个 总共分钟。同时，我们使用 make 进行 Netlify 构建 html-noplot 构建网站而不渲染笔记本 输出到 Pages 中以供快速查看。
接受 PR 后，将使用 GitHub 重新构建和部署站点 行动。