希望大家都度过了富有成效且愉快的 PTG！趁记忆犹新，我想花点时间总结 TC 讨论中的讨论和行动。
如果您对某个特定的行动项目感兴趣，请回复 邮件列表主题。
有关详细版本，请查看 PTG 的 etherpad。
简而言之;
以下是 TC 正在确定成员负责的 #ACTION 项目
- 启动面向用户的 API 弹出团队
- 撰写一份决议，说明解构后的 PTL 角色将如何运作
- 更新目标选择文档，说明一个或多个目标都可以；不必多于一个
- 两位志愿者开始 W 目标选择流程
- 为每个项目分配两名 TC 联络人
- 审查标签，确保它们仍然适用于驱动所有 OpenStack 项目的通用行为
以下是所有 TC 成员需要做的事情
- 审查上次的目标提案，以便我们可以决定接受或拒绝 V 版本的提案[4]
- 将阻碍 OpenStack 进展的系统添加到减少系统和摩擦列表中
- 继续您认为重要的对话
每个人都可以通过多种方式参与社区！只需访问 #openstack-tc IRC 频道，我们就可以为您指明方向。
星期二
======
Ussuri 回顾
—————————-
一如既往，我们取得了很大的成就。我们取得的一些成就包括枚举每个版本的操作系统（再次）、删除 python2 支持以及添加想法仓库。在发布结束时，我们围绕着无领导项目应该怎么做、PTL 的角色以及缺少下一版本 PTL 候选人的项目应该怎么做进行了大量讨论。我们讨论了办公时间、其历史和存在的原因，并明确了我们如何加强我们自己、项目和更广泛社区之间的沟通。
TC 入职培训
——————–
有人提出，最近当选的人（甚至前一次选举的新成员）觉得 TC 的入职培训不够充分。通过讨论我们可以做些什么来更好地支持回归成员，就是更好地记录 TC 成员应该执行的日常、每周和每月任务。Kendall Nelson 提出了一项补丁，开始向 TC 成员指南添加更多详细信息。 也有人提出，我们应该为有兴趣加入 TC 或新 TC 成员的更有经验的 TC 成员建立一种指导或影子计划。关于影子/指导计划的讨论将继续进行。
TC/UC 合并
——————
Thierry 介绍了委员会合并的最新情况。简而言之，目前的方案是 UC 成员从 TC 成员中选出，UC 在 TC 内部运作，并且鉴于拥有 AUC 身份的 TC 成员数量，我们已经为此做好了准备。所有这些都不需要修改章程。已经开始的下一步是 openstack-users ML 合并到 openstack-discuss ML。其他下一步是决定何时进行实际过渡（解散独立的 UC，可能在下一次选举时？）以及何时设置 AUC 作为额外的 ATC，纳入选举人团。有关更多详细信息，请查看 openstack-discuss ML 主题。
星期三
=========
求助列表
———————–
我们确定了职位发布的格式，并且列表上有几个。我们讨论了我们希望多久查看、更新或添加一次这些职位。建议每年进行一次。我们需要继续推动董事会，让公司致力于为这些项目贡献者，并让他们了解这是一种需要一年或更长时间才能看到回报的投资；实习生很好，但还不够。
TC 对基金会成员社区贡献的立场
———————————————————————————-
讨论从当前情况开始——白金会员的期望、会员在董事会中获得的利益以及他们应该为这些利益捐赠贡献者资源的原因等。提出了一些建议：强制执行或删除最低贡献水平、让金牌会员有机会提高知名度（也许给予他们一些白金会员的优势），如果他们用贡献者贡献来补充货币贡献等。 决定的 #ACTION 是让 Mohammed 将这些想法带给董事会，看看他们的想法。
OpenStack 用户界面 API
————————————–
用户对用户界面 API 的状态感到困惑；他们被告知使用 OpenStackClient (OSC)，但使用后发现缺少 python-*clients 中存在的特性。OSC 中的部分实现比服务只使用其特定的 CLI 更糟糕。OpenStackSDK 的成员加入了讨论，解释了项目过去在实施某些命令方面遇到的许多障碍已经得到解决。 建议创建一个弹出团队，并从完全迁移 Nova 开始，记录该过程并收集任何其他未解决的阻塞问题，希望有一天我们可以将剩余项目的迁移设置为社区目标。 补充说明，提出了一项新想法——强制新功能添加到服务时，仅添加到 SDK（以及可选的 OSC），而不是项目特定的 CLI，以阻止两个 CLI 之间的差异越来越大。 这里的 #ACTION 是启动弹出团队，如果您感兴趣，请回复！ 此外，如果您不同意这种强制执行，请尽快联系 TC 并说明您的担忧。
OpenStack 中 PTL 的角色和无领导项目
———————————————————————
这是一段非常漫长且循环往复的对话。 简而言之，我们 TC 愿意让项目团队自行决定是否希望通过将 PTL 角色分解为负责发布的人和负责安全问题的人来采用更解构化的 PTL 角色。 这种新格式还伴随着设定期望，即对于项目更新和注册 PTG 时间等事项，如果团队中的某人没有主动承担这些任务，则默认假设该项目将不会参与。 我们需要有人承担的 #ACTION 是撰写一份决议，说明这将如何运作以及如何进行。 理想情况下，这应该在下一次技术选举之前完成，以便团队可以在那时选择它。 如果您有兴趣承担撰写此决议的任务，请发言！
跨项目工作
————————-
-弹出团队-
我们目前有两个团队，即 Encryption 和 Secure Consistent Policy Groups。 两者都在缓慢进展，并将继续进行。
-减少每个周期内的社区目标-
从历史上看，我们每个周期有两个目标，但对于较小的团队来说，这可能是一项巨大的任务。 #ACTION 是明确概述目标提案和选择过程的文档，以澄清选择一个目标是可以的。 还没有人认领此行动项目。
-Victoria 目标最终确定-
目前，我们有三个提案和一个已接受的目标。 如果我们要选择第二个目标，则需要尽快完成，因为 Victoria 开发已经开始。 所有 TC 成员都应审查 上次请求选择的提案。
-Wallaby 周期目标讨论启动-
首先，#ACTION 是需要一位或两位 TC 成员来指导 W 目标选择。 如果您感兴趣，请回复此主题！ 有一些为 Victoria 提出的未通过的目标，可以作为 W 讨论的起点，特别是 rootwrap 目标，这对于操作员来说会很好。 OpenStackCLI 可能是 Wallaby 提出的另一个目标。
尽早检测未维护的项目
—————————————————
TC 联络人计划在几个版本前已经创建，但最初 TC 成员的负担很大。 我们讨论了恢复该计划，并在每个版本的开始或结束以及中间进行两次项目健康检查。 TC 联络人将查看先前提出的版本、团队的发布活动、tempest 插件的状态、是否定期召开会议、是否有正在进行的补丁以及项目的 IRC 频道有多繁忙，以做出判断。 由于每个项目将分配多个联络人，这些联络人可以根据自己的意愿分配工作。 仍然需要决定的另一个方面是健康检查将在哪里记录——在 wiki 中？ 在会议和会议记录中？ 该决定仍在继续进行。 当前未分配的 #ACTION 是我们需要为 Victoria 周期分配联络人并决定何时进行第一次健康检查。
星期五
=====
减少系统和摩擦以推动变革
—————————————————————-
这又是另一个循环往复的对话，直到我们意识到我们应该列出我们想要解决的更具体的问题，然后集思广益解决方案。 我们创建的列表（包括已经进行中的工作）如下：
- TC 与 UC 分开（解决方案正在进行中）
- 由独立团队批准稳定版本（解决方案正在进行中）
- 加快存储库创建速度（尤其是对于成熟的项目团队）
- 创建项目团队合并流程蓝图
- 需求团队只有一个人
- 稳定团队
- 整合代理体验
- 找出如何改进项目 <–> openstack 客户端/sdk 交互。
如果您有兴趣承担其中一项工作并开始提出解决方案或添加到列表中，请随时进行！
OpenStack 中的监控（Ceilometer + Telemetry + Gnocchi 状态）
—————————————————————————————–
这段对话也在进行中，但基本上我们讨论了当前的情况——它们维护得不好，并且 Ceilometer 部分依赖于 Gnocchi 增加了复杂性。 有一些想法可以研究，例如使用 oslo.metrics 作为所有工具之间的接口，或者如果我们能够清理这些依赖关系，则在没有 Gnocchi 的情况下使用 Ceilometer。 这里没有具体的行动项目，如果您有任何想法，请分享。
想法仓库后续步骤
——————————-
在 Ussuri 回顾中，有人提出我们可能需要更多地讨论我们对这个仓库的期望。 基本上，我们希望它成为一个收集想法的地方，而无需担心如何实现。 它应该是一个记录我们拥有的想法（新旧）的地方，并将所有讨论放在一个地方，而不是历史邮件线程、会议记录、其他 IRC 日志等。 我们决定定期浏览这个仓库，可能是在峰会上的论坛环节，看看是否有任何更新或将想法提升为社区目标等。
‘tc:approved-release’ 标签
———————————
Manila 团队从他们本周早些时候的讨论中提出了这个主题。 我们讨论了标签的历史以及标签的使用方式演变。 目前的方案是删除该标签，因为发布仓库中的任何内容本质上都是 tc 批准的。 Ghanshyam 已经自愿记录此操作并删除该标签。 还需要通知董事会，并查看治理仓库中的 projects.yaml 作为 TC 批准项目的真实来源。 未分配的 #ACTION 项目是审查剩余标签，看看是否有其他需要修改/删除/添加的标签，以驱动 OpenSack 组件的通用行为。
董事会提案
———————-
这是一个对我们进行过的所有讨论的快速总结，这些讨论对董事会有任何影响，并大致决定了谁会提及它们。
会话反馈
————————
这与许多其他主题相比也是一个相当快速的主题，我们讨论了所有讨论的进展情况（我们基本上称 PTG 成功），从后勤方面来说。
OpenStack 2.0：k8s 原生
———————————–
这个主题是在我们时间结束时提出的，所以我们没有时间真正讨论它。 基本上，Mohammed 想要开始讨论 将 k8s 添加为基础服务以及如果项目提出需要 k8s 会发生什么。 添加与 k8s 协同工作的服务可以为 OpenStack 打开创新之门。 显然，这个主题需要进一步讨论，因为在我们结束之前我们几乎没有开始。
提醒一下，以下是 TC 正在确定成员负责的 #ACTION 项目：
- 启动面向用户的 API 弹出团队
- 撰写一份决议，说明解构后的 PTL 角色将如何运作
- 更新目标选择文档，说明一个或多个目标都可以；不必多于一个
- 两位志愿者开始 W 目标选择流程
- 为每个项目分配两名 TC 联络人
- 审查标签，确保它们仍然适用于驱动所有 OpenStack 项目的通用行为
以下是所有 TC 成员需要做的事情
- 审查上次的目标提案，以便我们可以决定接受或拒绝 V 版本的提案[4]
- 将阻碍 OpenStack 进展的系统添加到减少系统和摩擦列表中
- 继续您认为重要的对话
享受下面的（经过 Photoshop 处理的）团队照片！
发表回复