企业组织贡献指南¶

什么是企业组织贡献指南？¶

一个指南提供给雇主，指出寻求贡献 OpenStack 的基本需求跟建议

建议¶

开发者参与¶

为什么我们需要让技术人员参与社群？¶

通过社区中的技术人员，您会发现在社区中触发开发任务或讨论更容易，以便最好地与您的业务/产品计划集成。

您需要人员来维护您的产品，就像社区需要人员在每个发布周期中维护项目以保持持续开发一样。

每个发布周期中有多个机会触发社区中的开发任务。为社区带来更多技术决策将有助于您从全球的开发人员和运营商那里获得更多反馈和指导。此外，帮助他们制定更好的周期目标，这对您也有好处。

应该派多少人？¶

取决于您自己的计划，请尽量涵盖您的业务所需的项目服务——不论是正在使用的还是计划使用的。

参与这些专案项目代表你可以：

监控专案项目健康状况
参与专案项目技术设计跟方向
参与并引导规划实践时的讨论
避免维护自家补丁

您在上游工作的人越多，您的功能就会得到更多的关注。提供更多的reviewer必将有助于合并您的实现到项目中。补丁落地的瓶颈就是代码审查，好的评价越多，代码落地越快。

他们应该要在那待多久？¶

最理想的答案是给予技术人力越多时间，而且越久越好

如果您的公司足够大可以做出选择，那么给工程师更多的时间专业化并专注于特定领域往往比工程师身兼多职不断上下文切换更有效。

让工程师在上游花费更多时间可以帮助每个人，为您设置为高优先级的任务提供持续的输入和反馈。但更重要的是，OpenStack依赖于同行评审。从代码的落地到管理，让项目运作需要社区人员的审查。

此外，让社区中的工程师长期工作也将使公司保持领先地位，因为他们已经嵌入并参与社区而非一暴十寒。

简而言之，公司在社区中投入的越多，获得影响力的可能性就越大。

为什么你需要跟技术社区同步¶

上游社区充满了热情和聪明的人，他们都想要最好的项目。参与意味着您可以帮助塑造和改进项目。

更好的是，不要在您自己的产品中Fork或添加下游补丁，这需要承载、支持和维护，这可能会非常昂贵。您可以将其推向上游，并因整个开发人员社区改进和维护它而获益。有效地消除了大部分（可能不是全部）维护下游的额外成本和风险。

它也将比内部开发的任何内容都更好地进行测试，因为它将由社区进行测试，并且比您的客户更广泛地使用。

所有这些额外的开发人员意味着更多的关注代码的查找、修复和改进。这意味着拥有一个开发人员社区，可以帮助您开发和改进自己的基础架构。

记着人多事情解决也快

技术¶

代码¶

访问review.opendev.org进行代码审查和代码提交。
- Port 29418/tcp is the Gerrit SSH API.
- Port 443/tcp is also available to access gerrit but only recommended if opening port 29418 is not possible, as it requires generating a password in the gerrit interface rather than using ssh certificates, so is inherently less secure.
  - https://docs.opendev.org/opendev/infra-manual/latest/developers.html#accessing-gerrit-over-https
- 有关我们如何使用gerrit的更多信息，请参阅：
  - 什么是 Gerrit?
  - 使用Gerrit

IRC （因特网中继聊天，Internet Relay Chat)¶

Access to chat.oftc.net port 6697/tcp (IRC communication)
- 如果使用IRC bouncer，可能需要连接到bouncer的443端口。
- 看设置IRC.

建议¶

一些基于浏览器的IRC服务，如irccloud，可以保持用户连接并使用标准HTTPS（443/tcp）。

如果某些端口的连接被锁定或出现问题，则可以使用SOCKS服务器提供访问。

电子邮件考量¶

能够同 lists.openstack.org（邮件列表）收发电子邮件。
- 邮件列表可能流量较高，考虑允许使用外部邮件服务来处理来自社区邮件列表的访问。
考虑发送到社区邮件列表的电子邮件上的签名和公司内部标准不同的情况。
看邮件列表 (ML, Mailing Lists).

操作系统（OS）注意事项¶

有许多与运行和开发OpenStack相关的组件和项目，都需要在Linux上运行。所以开发人员需要：

在雇主提供的硬件上运行Linux并安装其他开源软件的权限。

技术活动¶

邮件列表可能流量较高，考虑允许使用外部邮件服务来处理来自社区邮件列表的访问。

一些技术活动包括：

Project Technical Gatherings (PTGs)
峰会跟 Forums
运维见面会

此类活动的更多信息可查阅： https://www.openstack.org/community/events/

非技术¶

OpenStack是一个全球社区。与社区的互动意味着与来自不同时区和文化的人们一起工作和互动，因此还有其他非技术性建议有助于促进OpenStack社区的参与度，这些建议可以分为三个方面：沟通，文化和期望。

沟通¶

作为一个全球社区，来自世界各地的会员需要能偶尔在常规办公时间以外工作，交谈或开会，这是至关重要的。

一些异步通信媒介，例如电子邮件和gerrit，被大量使用，但有时这些讨论可以通过使用更多同步媒介来加速，例如：

IRC 对话
- 如果和来自全球不同地区的开发人员工作可能意味着需要找个所有人都在线的时间在IRC上聊天。
- 同样，在审查补丁时，与频道中的补丁作者交谈可以大大加快审查速度，尤其是对于更复杂的补丁。
IRC 会议
- 所有项目都定期召开IRC会议。大多数这些会议在两个不同的时区之间交替。但有时，让某个功能或项目的所有开发人员能同时聚在一起是有利的。
其他
- 其他项目可能会根据相关开发人员选择其他沟通方式，但透明度很重要。任何讨论的内容都应有日志或纪要，以供此OpenStack项目成员和世界上的其他人查看。

社区文化¶

时区
- OpenStack社区分布在不同的时区，因此总是尝试对更大的群体透明，如果使用同步通信系统做出功能/项目决策，请确保您可以收到其他时区成员的异步输入。
- 不同的时区意味着不同的文化，因此要对这些文化差异敏感。一个例子是让非英语母语人士有机会思考和说话，如果使用语音媒体，请放慢速度。
社区成员拥有的头衔是暂时的，活动与头衔无关。
- 这里的每个人都在齐心协力让OpenStack变得更好。
- 拥有头衔的每个人，例如PTL或技术委员会的成员都是选举产生的。所以头衔是暂时的。
Fork是不对的，直接向上游贡献更好些。
- 引用文章说明如何维护fork通常是一个费事且痛苦的过程（通过一些链接进一步了解如何有效地参与开源社区）(译注:原文周围暂无链接)
社区并未正式认可由Mirantis主办的贡献数据收集统计服务Stackalytics。社区不鼓励尝试通过提出大量低价值提交或对大量变更提案进行投票而不提供深思熟虑的评论来提高一个人的贡献统计数据。这样的行为对社区的其他成员而言就是在试图戏弄系统，参与其中的贡献者往往会让社区失去对自己和雇主的信任。相反，贡献者应该尝试深入参与单个项目或少数项目，以了解软件组件并与该项目的其他贡献者建立关系。
将员工聚焦于特定项目区域或针对特定目标比要求他们跟随许多项目的动态更有效。

期待¶

允许同意 OpenStack ICLA (必要)
允许偶尔将工作时间调整为非常规办公室时间
从IP角度清除贡献的过程
派遣贡献者参与活动的许可和预算
期望能出行参与部分活动（不需要全部参与）
- 应当能准备授权书、签证或者签证所需的材料
- The letters/decisions made on travel should be given out, ideally weeks or more, in advance
- Permission to agree with terms of becoming an Open Infrastructure Foundation Individual Member
考虑加入成为贡献组织名单的成员

企业组织贡献指南