PyTorch 治理 | 机制 ¶
摘要
PyTorch 采用一种层级式的技术治理结构。
一群提交问题、发起拉取请求并为项目做出贡献的贡献者社区。
PyTorch 项目的每个模块都由一小批模块维护者推动。
他们由核心维护者监督，核心维护者推动整个项目方向。
核心维护者有一位总负责人，是所有决策的最终决定者。
所有维护者都应强烈倾向于 PyTorch 的设计理念。
除了维护者之外，社区也被鼓励贡献力量、提交问题、提出建议、审查拉取请求并在社区中保持活跃。只要有贡献和投入的意愿，任何人都可以被接受为维护者，并获得代码库部分内容的写入权限或所有权。
技术治理与业务治理严格分离。将技术与业务治理分开确保任何个人或公司都无法“花钱进入”项目的技术指导。此外，技术治理过程的成员资格是针对个人的，而不是公司。也就是说，没有为特定公司预留席位，成员资格与雇佣该个人的公司无关。
模块维护者 ¶
模块被定义为 PyTorch 组织内的 GitHub 仓库，或为核心仓库 pytorch/pytorch 内的目录。每个模块都将有自己的维护者组。维护者组负责审查和批准提交、改进设计和更改模块的范围。每个维护者组都可以采用自己的规则和程序来做出决策（多数投票为默认）。模块维护者有权对其他模块维护者做出的决定提出异议——尤其是如果这影响到他们。当出现争议时，模块维护者组应提供合理的公开解释，包括争议、相关论点和解决方案。在模块维护者无法自行得出结论的例外情况下，他们将升级至核心维护者进行审查。升级由核心维护者根据其规则和程序解决。
每个维护者组应公开其模块的可用通信（一个愿景、粗略路线图、设计文档、任何争议和争议解决方案），以便贡献者和其他感兴趣方了解项目的未来方向并参与讨论。
维护者的职责包括：
对模块的高优先级问题进行分类处理
对模块的高优先级拉取请求进行分类、审查和合并
支持与模块相关的公共文档
举办公开的开发者会议
核心维护者 ¶
核心维护者应深入了解 PyTorch 代码库和设计理念。他们的职责包括：
阐述项目长期愿景的连贯性
以所有相关方都能接受的方式协商和解决有争议的问题
接收来自 PyTorch 利益相关者的广泛变更请求，并评估/接受它们（小型模块级请求由模块维护者处理）
核心维护者作为一个团队，有权否决在模块维护者级别做出的任何决定。核心维护者有权根据自身判断解决争端。核心维护者应公开阐述他们的决策，并清楚地说明他们的决策、否决和争端解决的理由。
核心维护者是 PyTorch GitHub 组织的管理员，并在维护者列表中列出。
首席核心维护者（BDFL）
可能存在核心维护者无法达成共识的决策。为了做出这样的困难决策，核心维护者中指定并公开宣布了一位首席核心维护者，在开源治理模型中也常被称为 BDFL。
首席核心维护者应公开阐述他们的决策，并给出明确的决策理由。首席核心维护者还负责确认或移除核心维护者。
任命、确认和移除维护者
原则
模块维护者小组的成员资格是根据个人在贡献、审查和讨论中展示的组件专业知识以及在整体 PyTorch 方向上与组件的契合度，基于业绩给予的。
要成为维护者小组的成员，个人必须展示出与整体 PyTorch 原则的强烈且持续的契合度。
模块维护者或核心维护者没有任期限制
如果他们在长时间内不积极参与，则将模块维护移至“荣誉”状态的轻标准。每个模块维护者组可以定义适合该模块的不活跃期。
会员资格是针对个人的，而不是公司。
提名流程 §
每个模块都有自己的流程。如需更多信息，请联系模块维护者。然而，如果没有识别出流程，您可以通过提交此表格向核心维护者提出请求。核心维护者每三个月举行一次会议。
如果您要向核心维护者提交请求，您的请求中必须包含以下信息：
提名人对于模块的代码、审查和设计贡献的深度和广度
提名人与维护者、用户和社区的互动评价（正面和负面）
维护者的一般支持评价
核心维护者随后评估所有信息，并做出最终决定，确认或拒绝提名。核心维护者的决定必须表达清晰，并将公开。
移除流程
与提名流程类似，社区中的任何人都可以提名某个人从模块维护者职位或核心维护者职位中移除。
一个人也可以自荐被移除
核心维护者（不包括存在利益冲突的人员）将要求或收集以下方面的更多信息：
他们在项目中的活动（或缺乏活动）
他们对该领域看法的变化，这导致与项目的整体方向产生冲突
其他使他们不适合担任维护者的信息，例如行为准则问题，他们在项目范围之外的活动与项目价值观相冲突
利益冲突：亲子或浪漫关系
核心维护者将评估所有信息，并最终决定确认或拒绝移除。核心维护者的决定必须阐述得很好，并将公开。
提名核心维护者
核心或模块维护者可以提名某人成为核心维护者
首席维护者（BDFL）负责评估提名
首席维护者要求或收集更多关于候选人成为核心维护者优势的信息：
来自其他核心和模块维护者的支持信
PyTorch 社区内部利益相关者的支持性信件
任何适合候选人资格的新相关资讯
主要维护者评估所有信息，并做出最终决定，确认或拒绝提名，并公开阐述其决策背后的理由。
移除主要核心维护者并提名新的主要核心维护者
核心维护者中的绝对多数（75%）可以选择移除首席核心维护者
在移除首席核心维护者或在不可预见的情况下（例如首席核心维护者永久不可用），核心维护者将遵循排名选择投票方法来选举新的首席核心维护者。
添加、移除和重新定义模块和项目
核心维护者共同负责在 PyTorch 组织内决定添加、移除和重新定义新模块，无论是作为 PyTorch GitHub 组织中的新仓库，还是作为 pytorch/pytorch 仓库中的文件夹。
他们邀请社区成员（包括他们自己）提出此类变更的提案。这些提案是开放式的，但应有一些基本的基础工作，以使变更的案例更具说服力。以下是一个处理此过程的示例方法：
访谈研究人员/利益相关者，与社区交流，收集问题；
阅读论文，参加会议，根据经验构建示例管道；
制定世界现状——确保此变更的必要性，例如添加新项目或模块值得维护成本；或者移除项目或模块不会从 PyTorch 中移除太多价值；
制定一份提案；一旦提案获得批准，该提案将涵盖维护权、开发和社区计划。
核心维护者对提案做出最终决定，并公开阐述决策背后的理由。
决策过程 ¶
无争议的变更 ¶
主要工作通过 GitHub 上的问题和拉取请求进行。维护者应避免直接将更改推送到 PyTorch 仓库，而应依赖拉取请求。核心或模块维护者批准拉取请求后，可以无需进一步流程即可合并。
通知相关专家关于问题或拉取请求非常重要。来自给定兴趣领域的专家的评审强烈推荐，尤其是在拉取请求批准时。未能做到这一点可能会导致相关专家撤销更改。
具有争议的决策流程
给定兴趣领域的重大更改需要开启 GitHub 问题进行讨论。这包括：
PyTorch 框架或库的任何语义或句法变更。
Python 或 C++ API 的向后不兼容变更。
核心框架或库的添加，包括现有库中的重大新功能。
核心功能或平台支持的移除。
核心模块维护者最终批准这些更改。
通用项目政策 ¶
PyTorch 已成为 PyTorch 系列 LF 项目，LLC。适用于 PyTorch 及其参与者的政策，包括商标使用指南，位于 https://www.lfprojects.org/policies/。
PyTorch 参与者承认，所有新贡献的版权将保留给版权所有者作为独立的作品，且不会要求任何贡献者或版权所有者将版权转让给项目。除非以下所述，所有对项目的代码贡献必须使用此处提供的 3-Clause-BSD 许可证：https://opensource.org/licenses/BSD-3-Clause（“项目许可证”）。所有外发代码将根据项目许可证提供。维护者可以在例外情况下批准使用替代的开源许可证或许可证，用于接收或发送贡献。
常见问题
Q：如果我想要拥有（或部分拥有）项目的一部分，例如功能区域或领域库，例如线性代数或 Torch Vision，这是绝对可能的。第一步是开始为现有项目区域做出贡献，并支持其健康和成功。此外，您可以通过 GitHub 问题提出新功能或改进项目区域的提案。
Q：如果我是一家公司，想要在内部使用 PyTorch 进行开发，我能获得或购买董事会席位来推动项目方向吗？不，PyTorch 项目严格遵循维护者项目哲学，并明确将技术治理与商业治理分开。然而，如果您想参与赞助和支持，您可以加入 PyTorch 基金会（PTF）并通过这种方式进行赞助。您还可以让个别工程师寻求成为维护者，但这不是保证的，而是基于功绩的。
Q: PyTorch 项目是否支持资助或支持独立开发者使用或贡献项目的途径？目前不支持。然而，我们正在寻找更好的方式来支持 PyTorch 周围的独立开发者社区。如果您有任何建议或意见，请通过 PyTorch 论坛联系我们进行讨论。
Q: 我如何向项目贡献代码？如果更改相对较小，可以立即在 GitHub 上打开一个 pull request 供项目提交者审查和合并。对于较大的更改，请先打开一个 issue 提出讨论建议。请参阅 PyTorch 贡献 Wiki 以获取贡献指南。
Q: 我能否成为项目的提交者？遗憾的是，目前向 PyTorch 提交代码的过程需要与 Facebook 基础设施交互，这只能由 Facebook 员工触发。然而，我们正在寻找方法将提交者基础扩大到 Facebook 之外的个人，并将提供更新，一旦存在允许这种操作的工具。
Q: 如果我想在会议或其他场合进行 PyTorch 教程的演讲，我需要是“官方”的提交者吗？不需要，我们鼓励社区成员在能展示自己工作的任何地方和任何时候都这么做。请通过 marketing@pytorchorg 联系市场支持。
