Open Development

Open Development 也是帮助 OpenStack 发展壮大的四大原则之一。 就像 Open Community（开放社区）和 Open Source（开源）一样，Open Development 允许与更广泛的社区互动，并欢迎更多成员加入。 Open Development 是项目庞大开发者社区和巨大协作模式的关键。

项目团队负责人 (Project Team Lead)

每个 OpenStack 项目都有一个项目团队负责人 (PTL)，由项目活跃贡献者在每个周期结束时选举产生。 PTL 负责承担其所服务的项目的管理领导责任。 这是一项志愿职位，与开源世界中的其他领导职位（例如 BDFL）没有直接关系。 项目由其社区驱动，PTL 在需要做出艰难决策时充当仲裁者。

核心审查员 (Core Reviewers)

核心审查员是 OpenStack 社区中志愿花时间审查特定项目的成员。 要成为核心审查员，感兴趣的人员需要为项目提供足够的审查，以证明他们理解项目结构、目标和策略。

从技术上讲，核心审查员是其参与的项目中拥有 +2/-2 权限的人。 可以成为多个项目的核心审查员，并且完全可以 - 并且建议 - 如果您的重点和优先级发生变化，可以随时辞职。

当项目没有活跃的维护者时

OpenStack 由全球志愿者社区构建和维护。 项目团队负责人 (PTL) 和核心审查员不是分配的角色，而是为了帮助指导和维持项目而挺身而出的社区成员。 随着时间的推移，这些个人可能会改变他们的关注点，有时项目团队或交付物可能会发现自己没有活跃的维护者。

理想情况下，项目内的活跃贡献者会提名和培养新的核心审查员以保持工作的进行。 但是，这并不总是及时发生。 如果您发现您感兴趣的项目或交付物缺乏活跃的维护者 - 例如，如果补丁没有被审查，或者 PTL 职位空缺 - 您不必等待或放弃。 您可以联系 OpenStack 技术委员会 (TC)。 TC 有兴趣帮助改革或振兴有社区兴趣的项目团队。 如果您愿意帮助维护这项工作，或者对如何由另一个团队采用该交付物有想法，TC 可以帮助协调过渡。

TC 可以

  • 将交付物重新分配给不同的项目团队。

  • 废弃不再使用的仓库。

  • 帮助招募和支持新的维护者。

  • 指导您完成组建或复兴团队的过程。

首先在 openstack-discuss 邮件列表上提出您的兴趣，或直接通过 OFTC 上的 #openstack-tc IRC 频道联系 TC。 务必描述您希望实现的目标以及您看到（或未看到）的项目情况。

您的主动性很重要 - 许多充满活力的 OpenStack 项目就是通过这种方式复兴的。 再次感谢您关心软件和社区的长期健康。

审查指南 (Reviews Guidelines)

审查是 OpenStack 开发工作流程中的关键步骤。 它要求审查者了解项目，以便能够提供出色的反馈并保证项目的更高质量。 然而，审查也是人们入门 OpenStack、开始贡献和学习感兴趣的项目的好地方。

为了使审查过程更容易，OpenStack 开发了一些旨在帮助审查者识别潜在问题并指导其与贡献者交互的指南。

  1. 一个简单的第一步是验证提议的代码是否符合项目的指南。 许多项目在其仓库中都有一个名为 HACKING.RST 的文件。 该文件包含该项目的基本指南。 如果没有该文件，则遵循 OpenStack 的通用指南是推荐的做法。 请注意，这些项目指南继承自 OpenStack 的指南。

  2. 验证提交消息是否也符合以下标准

    1. 标题长度不得超过 50 个字符。

    2. 摘要行应换行至 70 个字符。

    3. 确保标题和摘要正确描述了补丁的目标。 引用错误或蓝图是不够的。 有时补丁是针对更大问题的部分修复，在提交消息中明确说明所有这些非常重要。

    4. 确保提交消息已正确标记。 如果有 API 更改，则应使用 APIImpact 标志。 如果有安全影响，则应使用 SecurityImpact 标志。 如果有文档更改，则应使用 DocImpact 标志。

    5. 确保在提交消息中正确引用蓝图和错误

      1. Closes-bug: #12345

      2. Implements-blueprint: my-blueprint-slug

  3. 在审查了提交消息之后，将是一个深入研究更改本身的好时机。 在这样做的时候，请确保以下几点也适用

    1. 确保代码可读且易于维护。

    2. 确保代码同时支持 python2 和 python3。 建议使用 six 以获得兼容性。

通常，审查代码需要大量的时间和精力，并且每个审查者都应该花足够的时间来提供更好的评论和质量。 但是，在风格和主观论点方面，建议不要过于吹毛求疵。 找到正确的平衡并评估权衡与验证上述所有点同样重要。

每个审查者都有权对补丁进行投票 (+1, 0, -1)，只有核心审查员才能 +2, -2 并批准补丁。 这些投票中的每一个都会影响补丁本身，并传达对补丁的同意、不同意或错误。 因此，必须正确使用这些投票，并且审查者有责任这样做。 阅读 OpenStack 审查变更的方式 以获取有关如何适当使用不同投票的指导。

规范 (Specifications)

每当需要引入引入新功能、破坏兼容性或需要讨论的更改时，您就需要一个规范（以下简称 spec）。 规范不过是一个 RestructuredText 文件，其中包含有关提议的更改和此更改尝试解决的问题的足够信息。

规范的形式可能会因项目和目标更改而异。 但是，提出这些规范的流程对于每个项目都是相同的。 规范应提交到项目的规范仓库，并遵循与其他补丁相同的贡献流程。 这保证了讨论和提案保持开放，并支持我们的开放开发原则。

项目可能对规范提案和批准有或没有截止日期。 这些项目也可能有一个略微不同的流程，并且负责审查这些规范的团队可能不是相同的。

就像 OpenStack 的文档一样，合并的规范会被渲染并在网上发布。 可以在 https://specs.openstack.org 上找到它们。