CNCF 在 KubeCon 北美大会启动用户组计划

CNCF 终端用户社区在 KubeCon + CloudNativeCon North America 上正式启动其用户组（User Group）计划。这些用户组是长期存在的组织，每个都围绕某个行业垂直领域或问题域建立，服务于终端用户社区的共同需求，并直接向 CNCF 技术咨询委员会（TAB）汇报。

为什么需要用户组

云原生在电信网络、研究实验室、公共机构和软件公司的平台团队中，落地形态各不相同。每个领域都有自己的约束条件、术语体系以及工具生态中的空白。CNCF 用户组为这些社区提供了一个持久稳固的组织场所，让它们能够围绕自身需求开展协作，而不必依赖那种做完一个项目或办完一场活动就消散的一次性努力。

用户组是该计划的主要组织单元。它与某个行业垂直领域、某个问题域或 CNCF 终端用户社区的某项共同需求相对应，并且从设计上就是长期存在的：用户组为项目及采用这些项目的组织履行常设职能。每个用户组：

• 代表并服务其所在领域的终端用户需求
• 识别 CNCF 项目组合中的空白，并帮助引入项目来填补这些空白
• 以客观、实用的云原生相关内容为用户提供教育
• 提出由社区贡献的参考架构、最佳实践和操作指南以供发布
• 就可用性、可靠性和性能向 CNCF 项目提供反馈

用户组同时也承担相应的责任。每个用户组都在一份章程（charter）下运作，由 TAB 批准的主席领导，至少每月举行一次公开会议，会议会被录制并发布到 YouTube，并定期向 TAB 汇报其健康状况和工作进展。各用户组还被期望在 KubeCon + CloudNativeCon 上亮相，无论是通过演讲、展位还是生态更新。

技术社区组与用户组：有何区别？

该计划被设计成一条路径，而不是一扇单一的门。技术社区组（TCG）是轻量级的起点：它们属于更广泛的 CNCF 社区组计划的一部分，作为实践者讨论某个话题、分享知识并协调未来可能举措的集结地。用户组则是其上层长期存在、拥有章程的层级。

该治理模式预期未来大多数用户组会以社区组的身份起步。一个希望升级的 TCG 必须已完成大量举措、覆盖现有用户组尚未服务的空白，并获得 TAB 批准。随后该组起草一份界定范围的章程，由 TAB 对其进行投票。投票通过后，用户组即告成立。来源：用户组治理。

一个入口，两个去向

社区组是贯穿 CNCF 的共享入口。TCG 最终去往何处取决于其关注点。由终端用户驱动的领域（例如某个行业垂直领域）归 TAB 管理，成为用户组。以项目为中心的领域归技术监督委员会（TOC）管理，可以成为技术咨询组（TAG）。治理文件建议 TCG 组织者尽早与 TOC 和 TAB 主席沟通，以便该组落到正确的位置。

TAG 路径与用户组路径形态相同。申请成为 TAG 的 TCG 必须已完成大量举措、覆盖当前已定义各组中的空白、拥有与母组协作的书面记录，并获得 TOC 批准。随后该组起草一份章程，由 TOC 对其进行投票，投票通过后 TAG 即告成立。来源：技术组治理。

平台工程：从 TCG 到用户组

平台工程社区展示了这条路径在实践中如何运作。它最初是前 TAG App Delivery 下的一个工作组，在去年的 TAG 重组期间成为技术社区组，如今正转型为用户组。随着时间的推移，该组从对话走向产出，包括平台工程成熟度模型（Platform Engineering Maturity Model）和平台白皮书（Platforms White Paper）。

成为用户组改变了该社区能够做的事情。它现在拥有 TAB 批准的章程、直接向 TAB 汇报的渠道、常设的公开月度会议，以及在 CNCF 生态中代表平台工程终端用户的正式角色。其重点领域包括内部开发者平台、黄金路径、自助服务能力、平台即产品、开发者体验，以及 GitOps 和策略即代码等运维实践。

“被认定为 CNCF 用户组对我们来说是一个激动人心的里程碑。它印证了我们社区成员多年来的付出，并提供了我们所需的更高可见度，以便引入新想法、吸引新人才，共同继续塑造平台工程的未来。” – Chris Plank（又名 Planko）

四个用户组，以及成长空间

该计划以四个用户组启动，每个服务于一个不同的终端用户社区：

• 平台工程：面向平台工程终端用户的云原生协作
• 公共部门：面向公共部门终端用户的云原生协作
• 研究：面向研究机构和科学工作负载的云原生协作
• 电信：面向电信终端用户的云原生协作

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）