SIG 治理
特别兴趣小组 (SIG) 是负责其特定 CentOS 项目变体的团队。变体是 CentOS 的专业化和聚焦的重建版本，旨在满足其相应社区以及与这些社区相关的技术的需求和要求。

SIG 通常由一小群爱好者和感兴趣的参与者围绕一项技术自发组成。除了现有的 CentOS SIG 之外，预计还将创建更多经 CentOS 董事会批准的 SIG。

每个小组将负责其在 CentOS 中专门针对其社区的变体（例如，CentOS FooBar SIG 创建一个针对 FooBar 用户和开发人员的 CentOS 变体，CentOS Hosting SIG 为网络主机构建一个变体，并包含在 CentOS 发行版中）。SIG 是决定其变体中需要什么来满足其社区需求的决定性权威，但董事会拥有最终监督权，如其他地方所述。如果需要，CentOS 董事会将协助各个 SIG 就任何问题或难题达成共识。

SIG 是实体使用 CentOS 品牌并将其与变体关联的唯一方式。您始终可以使用 Git 和仓库进行分支并尝试想法，但只有 git.centos.org 中并由 CentOS 发布和签名的软件包才能被称为“CentOS”。

另一种类型的 SIG 是功能性的，专注于维护项目本身的部分，例如基础设施、文档和设计。一个独特的 SIG 是核心 SIG，它构建并维护 Red Hat Enterprise Linux 的核心 CentOS 衍生版本。它是独特的，因为它是一个中心、协调的平台，所有其他变体都基于它构建。

CentOS 核心 SIG 的职责

  • 构建 CentOS 发布版。
  • 签署 CentOS 发布版。
  • 将官方 CentOS 发布版推送到初始镜像。
  • 根据需要与上游协调。
  • 接受 Git 中的更改。
    • 管理 Git 许可和贡献政策。

变体 SIG 的职责

  • 在 CentOS 核心基础上创建和维护一个或多个具有技术的变体，或对其进行修改。
  • 将培养用户社区作为变体的主要目的。
    • 保持项目产物（变体）与用户社区相关且有用。
  • 确保为支持变体而引入的软件已正确许可和准备，以便作为 CentOS 项目的一部分进行打包和分发。
  • 监督与变体相关的代码纳入 git.centos.org。
  • 遵循开放源代码的精英管理和共识决策实践，开展 SIG 业务。

功能性 SIG 的职责

  • 负责设计、构建和维护关键项目组件。
  • 使功能领域开放参与，并尽可能合理地降低贡献障碍。
  • 围绕功能方面培养用户和贡献者社区，以分担责任、工作量和创新。
  • 在给定的法律约束和要求内工作。

SIG 治理

SIG Governance

SIG 本身也有一个精英路径，可以走向项目方面的自主权和责任。精英水平的确定反映在董事会所需的监督量以及 SIG 自行签署和发布软件构建的能力上。随着精英水平的提高，董事会监督会降低，中间有一个过渡点，SIG 自然会获得更多自主权，通常在“早期”阶段结束时。

沙盒是所有提议的 SIG 的入口点。要进入，必须有来自董事会或经董事会批准的负责人，以及一份提案（其中说明了 SIG 的原因、预期受众、初始团队、风险等）。要创建一个 SIG，必须获得董事会至少 3 票 +1（不包括负责人）和零 (nil) -1 票。获得批准后，负责人成为沙盒 SIG 的正式导师。

沙盒不能进行正式发布，但可以创建允许人们、开发人员等使用、测试和玩耍构建的发布。沙盒也受到董事会的密切监控，以确保它们正在吸引兴趣，并且开发人员和用户正在学习 SIG 运营的窍门。所有新的提交者、开发人员、SIG 核心团队成员等都必须获得董事会批准。

经董事会确定的已达到一定精英水平的 SIG 将进入早期 SIG 阶段（沙盒如果愿意可以申请晋升到早期）。这些 SIG 允许创建正式发布，但发布必须经董事会批准并由导师签署。然而，在所有其他事项上，它们都是自给自足的，不再需要董事会批准，例如在添加提交者等方面。从沙盒到早期的移动需要董事会 3 票 +1（不包括导师）和零 (nil) -1 票。

最后阶段是成熟 SIG。同样，这种晋升是基于董事会的判断和决定，但这种移动必须是董事会的一致决定。成熟 SIG 对 SIG 拥有完全控制权，将自己的源代码拉入 git.centos.org，其发布、其内部治理，并能够自行签署发布。董事会成员可以随时投票或参与任何 SIG 决定。

在沙盒和早期 SIG 中，董事会的作用主要是促进这些 SIG 向成熟级别发展；它充当一个初始门户，目标是让 SIG 摆脱束缚。

请注意，在所有情况下，成熟度都是衡量社区本身的指标，而不是代码库或实际的 SIG 变体发布。一个成熟的 SIG 可以创建一个非成熟的（例如，Alpha 或 Beta 发布）发行版，反之，一个沙盒 SIG 可以产生一个非常成熟（健壮且可靠）的发行版。

社区和 SIG

SIG 代表了 CentOS 项目的真正力量和价值。正如当前的 CentOS Dojo 和 CentOS 社区本身所见，这些构建为主要技术领域提供了一个安全、中立和公共的中心聚会场所。这就是为什么 SIG 不应特定于程序/项目（例如，MariaDB 重建），而应专注于技术领域（例如，“主机”重建）的原因。通过创建一个所有项目和社区都可以交互的中心点，以操作系统作为共同基础，上游项目将能够接触到更广泛的受众并与之交互。

预计 SIG 可能会提议对 CentOS 核心基础进行重大分叉，例如引入新的 Python 版本或 Linux 内核。董事会和 CentOS 核心 SIG 的职责是监督和批准任何被拉回 Git 的分叉，包括确保这些分叉是可支持的。这种支持最好由一个活跃且参与的变体 SIG 来完成。如果董事会或 CentOS 核心 SIG 合理地认为变体 SIG 无法支持该变体，他们可以从发布中撤回该变体。另一个选择是将一个活跃的变体从一个死的 SIG 重新分配给一个愿意的活着的 SIG。董事会特别不限于可以采取什么措施来保护 CentOS 标记在变体内容和质量方面的质量。

创建新的 SIG

创建新 SIG 的过程涉及两个主要组成部分：社区建设和管理方面。

首先将您的 SIG 提案提交到 centos-devel 邮件列表，以寻找其他志同道合的人与您一起启动 SIG。也可以在 CentOS 项目之外寻找可能希望在 CentOS 上分发项目的人。

一旦您有一个核心小组想要实现这一点，请在董事会问题跟踪器上提出一个包含您提议的 SIG 的工单，那里会有人引导您完成整个过程。

有关当前活跃 SIG 的列表，请参阅http://wiki.centos.org/SpecialInterestGroup

废弃 SIG

如果一个 SIG 连续两次未提交季度报告：那么社区经理应联系账户系统中列出的成员。应进行不止一次的联系尝试。如果 SIG 回复，则可以正确分类。如果他们在 45 天内没有回复，则可以被视为不活跃。

如果 SIG (a) 未能回复，(b) 回复说 SIG 已完成其预期的工作且无需进一步工作，或 (c) 回复说他们已决定放弃努力，则应执行以下操作。

(1) 应向 CentOS Devel 发送公告，表明该 SIG 即将终止。如果成员认为他们可以重新激活该 SIG，这将是阻止其废弃的时间。(2) 应为仅用于通知目的而打开一个董事会工单，以便董事会可以跟踪是否突然有大量 SIG 退出。(3) 应向基础设施部门打开一个工单，以归档 SIG 材料。应采取措施，既要考虑对过去成员工作功劳的认可，又要考虑希望从档案中取消列出的成员的意愿。