TripleO Squads¶
在 OpenStack 中，团队规模扩大是一个常见的挑战。我们总是会增加项目的数量，以及贡献者的人数，这通常意味着组织结构上的一些变化。本策略旨在记录 TripleO 项目将如何应对这一挑战。
问题描述¶
项目通常从一个 git 仓库开始，并且经常发展到十几个仓库，做不同的事情。随着项目逐渐成熟，共同处理同一主题的人员需要一个开放协作的空间。目前，TripleO 作为一个单一的团队运作，每周在 IRC 上开会讨论 bug、CI 状态、发布管理。同时，新贡献者也经常难以找到一个可以快速开始贡献的领域。开发人员的时间非常宝贵，我们需要找到一种方法来让他们能够专注于自己的工作领域。
策略¶
本策略的目的是创建由从事同一主题的人员组成的团队，并允许他们专注于工作，减少外部干扰。
任何人都可以自由地加入和离开一个团队，这完全取决于个人意愿。目前，团队规模没有限制，因为这仍然是一个实验性的做法。如果发现一个团队太大（超过 10 人），我们可能会重新考虑团队的关注领域。
任何人都可以同时加入一个或多个团队。团队将在一个任何人都可以贡献的地方进行记录。
团队可以自由地组织每周会议。
#tripleo 仍然是官方 IRC 频道。我们不会添加更多频道。
团队需要选择一名代表，作为团队与 TripleO PTL 的联络人。
TripleO 每周会议仍然会存在，鼓励任何人加入，但讨论主题将保持在高层次。一些主题示例：发布管理；团队之间的横向讨论、CI 状态等。会议将是 TripleO 跨项目的会议。
我们可能需要测试这个想法至少 1 或 2 个月，并投入时间来反思哪些有效，哪些可以改进。
优势¶
预计从事同一主题的人员之间的协作会更多。这将正式反映我们在过去几个周期中几乎已经做到的事情。
从事 TripleO 同一领域的人员将有机会进行公开和开放的会议，任何人都可以自由加入。
新成员将更容易理解 TripleO 项目提供的功能，因为团队将提供我们所做工作的良好概述。同时，这也将为希望学习 TripleO 特定领域的人员提供加入新团队并向他人学习的机会。
开放更多可能性，例如为每个团队建立指导计划，或提供特定的文档以便更快地参与其中。
挑战¶
我们需要避免创建孤岛并保持横向协作。在团队中工作并不意味着你需要忽略其他团队。
团队¶
该列表在每个周期中都可能发生动态变化，具体取决于团队正在处理的主题。以下列表可能会随着团队的变化而变化。
团队 |
描述 |
|---|---|
ci |
专注于持续集成工具和系统的团队 |
升级 |
专注于 TripleO 升级的团队 |
validations |
专注于 TripleO 验证工具的团队 |
networking |
专注于 TripleO 中网络部分的团队 |
integration |
专注于配置管理（例如：服务）的团队 |
安全 |
专注于安全的团队 |
edge |
专注于边缘/多站点/多云的团队 https://etherpad.openstack.org/p/tripleo-edge-squad-status |
transformation |
专注于将 heat 模板 / puppet 转换为 Ansible，在 tripleo-ansible 框架内的团队 |
注意
关于 CI 的说明：该团队致力于使用 OpenStack Infra 测试 TripleO 的工具，尽管每个团队都负责维护其测试的良好状态。
替代方案与历史¶
另一种选择是继续以这种方式进行，并保持一个单一的横向团队。只要我们尝试在团队中欢迎新成员并添加更多项目，就会增加 TripleO 项目规模扩大的问题严重性。涉及的人数和主题的多样性使得能够处理所有事情变得非常困难。
实现¶
里程碑¶
进行中
工作项¶
与 TripleO 开发人员合作，记录每个团队的工作领域。
记录输出。
记录团队成员。
如果需要，设置团队会议。
为每个团队找到联络人或团队负责人。
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
