[ English | 한국어 (대한민국) | Indonesia | 中文 (简体, 中国) | español (México) | English (United Kingdom) | Deutsch ]
贡献组织指南¶
什么是贡献组织指南？¶
一份概述了希望为 OpenStack 做出贡献的员工的基本要求和建议的指南。
建议¶
开发者参与¶
为什么我们需要向社区派遣技术人员？¶
有了社区中的技术人员，您会发现更容易触发社区中的开发任务或讨论，从而最大限度地提高与您的业务/产品计划集成的机会。
您需要人员来维护您的产品，就像社区需要在每个发布周期中需要人员来维护项目以保持开发一样。
在每个发布周期中都有多种机会来触发社区中的开发任务。将更多的技术决策带入社区将帮助您获得来自全球开发者和操作员的更多反馈和指导。 此外，帮助他们制定更好的周期目标，这对您也有益。
您应该派遣多少人？¶
取决于您自己的计划，但请尝试涵盖您正在使用或计划用于您的服务的一系列项目服务。
参与这些项目意味着您可以
监控项目的健康状况。
参与项目的设计和方向。
参与并塑造实施讨论。
避免携带下游补丁。
您投入上游的人员越多，您的功能获得的关注就越多。提供更多的审查者肯定有助于将您的实现合并到项目中。代码审查是着陆补丁的瓶颈，更多的良好审查可以更快地着陆代码。
他们应该在那里待多久？¶
理想的答案是尽可能地给予技术人员尽可能多的时间百分比，并尽可能长的时间。
如果您的公司足够大，可以选择，给予工程师更多的时间来专门研究和专注于特定领域往往比让工程师不断切换上下文更有效，因为他们不得不戴多顶帽子。
让工程师花更多时间在上游有助于每个人提供对您设定的高优先级任务的持续输入和反馈。但这不仅仅是这样，OpenStack 依赖于 同行评审。从着陆代码到其治理，项目需要社区中的人员进行评审才能正常运行。
此外，长期在社区中拥有工程师也将使公司保持领先地位，因为他们嵌入并参与社区，而不是进进出出。
更简单地说，公司在社区中的投入越多，他们更有可能获得影响力。
为什么需要与技术社区同步？¶
上游社区充满了充满热情和智慧的人，他们都希望项目达到最佳状态。参与意味着您可以帮助塑造和改进项目。
更好的是，与其分叉或在您自己的产品中添加下游补丁，然后您需要携带、支持和维护这些补丁，这可能非常昂贵。您可以将其推送到上游，并从整个社区的开发者那里获得好处，他们将与您一起改进和维护它。有效地消除了大部分（如果不是全部）维护下游的额外成本和风险。
它也将比内部开发的东西得到更好的测试，因为它将由社区测试并在您的客户之外更广泛地使用。
所有这些额外的开发者意味着更多的人关注代码，发现、修复和改进代码。这意味着拥有一个开发者社区帮助开发和改进您自己的基础设施。
请记住，人多力量大。
技术¶
代码¶
访问 review.opendev.org 以进行代码审查和代码提交。
端口 29418/tcp 是 Gerrit SSH API。
端口 443/tcp 也可用于访问 gerrit，但仅建议在无法打开端口 29418 时使用，因为它需要在 gerrit 界面中生成密码而不是使用 ssh 证书，因此本质上安全性较低。
有关我们如何使用 gerrit 的更多信息，请参见
互联网中继聊天 (IRC)¶
访问 chat.oftc.net 端口 6697/tcp（IRC 通信）
如果使用 IRC 跳线器，可以使用端口 443 到跳线器。
请参阅 设置 IRC。
建议¶
有基于浏览器的 IRC 服务，例如 irccloud，它将保持用户连接并使用标准的 HTTPS (443/tcp)。
如果某些端口的连接被锁定或存在问题，可以使用 SOCKS 服务器来提供访问权限。
电子邮件注意事项¶
能够从 lists.openstack.org 地址接收电子邮件并向其发送电子邮件（邮件列表）
邮件列表流量很大，请考虑允许使用外部邮件服务来处理来自社区邮件列表的输入。
考虑对发送到社区邮件列表的电子邮件中的标准电子邮件页脚进行例外处理
请参阅 邮件列表 (ML)。
操作系统 (OS) 考虑因素¶
与运行和开发 OpenStack 相关的大量组件和项目都运行在 Linux 之上。因此，开发人员需要
允许在雇主提供的硬件上运行 Linux 并安装其他开源软件的权限。
技术活动¶
举行了许多技术活动，社区、项目和跨项目规划和人际交往都在其中进行。 尽管这些规划和人际交往在这些活动之外也可以在线进行，但您应该考虑派遣开发人员参与其中。
一些技术活动包括
项目技术聚会 (PTG)
峰会和论坛
运营商见面会
有关此类活动的更多信息，请参见：https://openstack.org/community/events/
非技术¶
OpenStack 是一个全球社区。与社区互动意味着与来自不同时区和文化的人一起工作和互动，因此还有其他非技术建议可以促进参与 OpenStack 社区，这些建议可以分为三个领域：沟通、文化和期望。
沟通¶
作为一个全球社区，成员来自世界各地，偶尔可以在典型的办公时间之外工作、交谈或会面至关重要。
一些异步通信媒介，例如电子邮件和 gerrit，被广泛使用，但有时可以通过使用更同步的媒介来加快这些讨论，例如
IRC 对话
如果开发人员来自世界上的不同地区，则可能意味着找到一个所有参与者都可用的时间来在 IRC 上聊天。
同样，在审查补丁时，与补丁作者在频道中交谈可以大大加快审查速度，尤其是对于更复杂的补丁。
IRC 会议
所有项目都在 IRC 上定期举行会议。大多数这些会议在两个不同的时区之间交替进行。但是，有时让所有致力于某个功能或项目的开发人员同时出现在一个地方是有利的。
其他
其他项目可能会根据相关开发人员选择其他通信方式。但透明度很重要。讨论的任何内容都应记录或记录下来，供 OpenStack 项目和世界上的其他人查看。
社区文化¶
时区
OpenStack 社区分布在不同的时区，因此始终尝试对更大的社区保持透明，并且如果使用同步通信系统来做出功能/项目决策，请确保您能够进行来自其他时区成员的异步输入。
不同的时区意味着不同的文化，因此对这些文化差异要敏感。一个例子是给非英语母语人士思考和说话的机会，如果使用语音媒介，请放慢速度。
社区成员的头衔是临时的，活动与头衔没有真正的联系。
我们都在一起努力，为了更好的 OpenStack。
拥有头衔的人，例如 PTL 或技术委员会的一部分，都是被选举产生的。因此，头衔是临时的。
分叉不好，贡献上游更好。
引用有关维护分叉通常是一个昂贵且痛苦的过程的文章（通过指向有关有效开源社区参与的进一步阅读的链接）
社区不正式认可 Stackalytics，Mirantis 托管的贡献统计信息收集服务。社区不鼓励试图通过提出大量低价值提交或对大量变更提案进行投票而不提供深思熟虑的审查来提高自己的贡献统计信息。其他社区成员会将这些活动视为试图操纵系统，并参与其中的贡献者及其雇主通常会在社区中失去信誉。相反，贡献者应尝试深入参与单个项目或少量项目，以了解软件组件并与该项目的其他贡献者建立关系。
将员工集中在特定项目领域或特定目标上比让他们跟踪许多项目上的活动更有效。
期望¶
允许同意开发者行为准则 - DCO（必需）
允许偶尔在典型的办公时间之外工作
一个从知识产权角度清除贡献的过程
允许并预算向活动派遣贡献者
期望至少参加一些活动 - 不需要全部
应该准备好撰写许可信/签证信/获取签证所需的信件
旅行的信件/决定应提前几周或更长时间发出
允许同意成为 Open Infrastructure Foundation 个人会员的条款
考虑注册为贡献组织成员
