# CubeFS 治理

## 原则

CubeFS 社区遵循以下原则：

- 开放：CubeFS 是开源的。
- 欢迎和尊重：请参阅 [行为准则](CODE_OF_CONDUCT.md)。
- 透明和可访问：对 CubeFS 组织、CubeFS 代码库和 CNCF 相关活动的变更（如级别、参与等）均在公开场合进行。
- 贡献：根据技术优点及与项目目标、范围和设计原则的一致性接受想法和贡献。

## 技术指导委员会（TSC）的期望

CubeFS TSC 是 CubeFS 项目的管理机构：
- 提供与其章程相关的决策和监督。
- 定义项目的价值观和结构。
- 负责项目的顶层设计、路线图的制定和社区管理。
- 批准创建和解散特别兴趣小组（SIG）。
- 建立和维护项目的整体技术治理指南。
- 如果无法达成共识，通过多数票做出决定。

## 技术指导委员会的结构

- TSC 成员也是维护者，只有 TSC 成员可以被视为核心维护者。
- TSC 成员的组成包括来自独立开发者或供应商的维护者。
- 为确保公平，将努力保持来自不同供应商的人员的平衡代表性。
- 任一单一供应商的人员不得超过总人数的 50%。
- TSC 的任期为两年。
- TSC 由 5 人组成。

## TSC 决策流程

在 TSC 任期的第一年，如果 TSC 会议缺少法定人数，将启动电子邮件投票程序。如果电子邮件投票在一周内也未能达到法定人数，则该议案将被视为通过，除非 TSC 成员有异议。

## 成为 TSC 成员

TSC 职位的任期为两年，个人可以多次担任该角色。TSC 成员的变更通过打开 GitHub PR 进行。

- **标准**：提名者必须是维护者，在过去两年中对社区做出过重大贡献，并在社区中拥有足够的声誉和影响力。
- **提名**：
	- 每个选择小组的个人可以提名最多 2 人，最多 1 人可以来自同一相关公司的组。每位提名者必须在被加入提名名单之前同意参与。允许自我提名。每位提名者需要来自不同组织/公司的其他 2 名贡献者的支持。
	- 提名必须公开，并应包含提名者的姓名、联系信息和经验说明。当前 TSC 将确定提名、资格和新 TSC 成员选举的流程和时间表。
- **选举**：
	- 如果合格提名者的数量等于或少于可选 TSC 座位的数量，则合格提名者将在提名期结束后获得批准。
	- 如果合格提名者超过可选 TSC 座位的数量，则选择小组将通过 Condorcet 投票选举 TSC 成员。
	- Condorcet 投票将通过康奈尔在线服务（https://civs.cs.cornell.edu/）使用 Condorcet-IRV 方法进行。
	- 只有以下投票具有约束力：
		- 在 PR 开启之前已在顶级 [MAINTAINERS](MAINTAINERS.md) 文件中列出的任何维护者。
		- 任何组织的维护者可以为该组织投票。然而，任何组织的有效投票不得超过总维护者数量的 1/2。

PR 应在任期结束前不早于 4 周打开。PR 应保持开放不少于 2 周。PR 只能在最后任期结束后合并，并在有效投票中获得 +1 多于 -1 后。

TSC 将在正式化此组织结构后的 3 个月内决定并公布选举流程。这将涵盖投票资格、候选资格、选举流程和时间表。

## TSC 的变更

- 如果 TSC 成员感到无法履行“对 TSC 的期望”，他们可以自愿辞职。

在这种情况下：
- 需要通过 PR 更新相关人员的 TSC 角色为普通维护者。
- PR 应由 TSC 成员审核。
- TSC 成员提名可在 2 周内开始，以增加新 TSC 成员并确保 TSC 的正常运作。

## 项目治理的变更

- 项目治理（GOVERNANCE.md）的变更可以通过打开 GitHub PR 来发起。
- 任何CubeFS TSC成员都可以对PR投票，票数达到大多数（即+1或-1）即可通过。
- PR 应保持开放不少于 2 周。

## 对维护者的期望

- 项目治理：提出项目的政策和指南，包括贡献指南和行为准则。
- 路线图和战略：提出项目路线图和战略方向，包括决定开发的功能和项目的优先级。
- 发布管理：管理发布过程，包括设置发布日程、协调发布活动，并确保发布经过适当测试和文档。
- 社区参与：建立和促进围绕项目的积极社区，包括欢迎新贡献者、解决冲突和推广项目。
- 提交者管理：管理提交者组，包括添加新提交者、移除不活跃者和处理团队内的争议。

每位维护者都列在顶级 [MAINTAINERS](MAINTAINERS.md) 文件中。

## 维护者的结构

- 维护者的组成由独立开发者或供应商组成。
- 任一单一供应商的人员不得超过总人数的 50%。
- 维护者由 10 到 15 人组成。

## 成为维护者

- **标准**：在成功合并一个重要的拉取请求后，或者在做出重大贡献后，任何现有维护者可以联系该拉取请求的作者，询问他们是否愿意成为 CubeFS 维护者。
- **提名**：维护者有权通过发送电子邮件至 maintainers@cubefs.groups.io 或打开拉取请求提名新维护者。
- **选举**：通常，新维护者是在提交者中选出的。TSC 将通过多数投票审查提案，审核通过后，您将收到社区的邀请信。

## 维护者身份的变更

- 如果维护者感到无法履行“对维护者的期望”，他们可以自愿辞职。
- TSC 将根据以下因素调整维护者名单：
	- 维护者在过去六个月内的活跃水平和贡献水平。
	- 跨模块的人员平衡。
	- 模块变更，如新增或弃用。
	- 供应商间的人员平衡。

在这种情况下：
- 需要通过 PR 将相关人员从维护者条目移动到 MAINTAINERS.md 的退休条目。这作为最后的联系尝试，以便他们提供反馈。
- 失去身份的维护者：
	- 访问 https://maintainers.cncf.io/ 并打开 PR 以在 CubeFS 下移除他们；
	- 从 cubefs.groups.io/g/maintainers 邮件列表中移除他们。

## 对提交者的期望

- 代码贡献：编写和提交对项目代码库的更改。
- 代码审查：审查和批准其他贡献者提出的代码更改，在合并到主分支之前。
- 文档：更新和维护与项目相关的文档。
- 缺陷和问题：帮助整理和解决用户报告的缺陷和其他问题。
- 功能开发：根据项目路线图和社区反馈实施新功能。

## Committers的结构
- Committers的组成包括来自独立开发者或供应商。
- 任何单一供应商的人数不得超过总人数的50%。
- Committers人数为10到15人。

## 成为提交者

- **标准**：在成功合并一个有意义的拉取请求后或在做出某些贡献后。
- **提名**：
	- 任何现有维护者可以联系拉取请求的作者，询问他们是否愿意成为 CubeFS 提交者。
	- 贡献者也可以自我提名，发送电子邮件至 maintainers@cubefs.groups.io 或打开拉取请求，并列出他们的贡献。
- **选举**：TSC 将在内部通过多数投票审查提案，审核通过后，您将收到社区的邀请信。

## 提交者身份的变更

- 如果提交者感到无法履行“对维护者的期望”，他们可以自愿辞职。
- TSC 将根据以下因素调整维护者名单：
	- 提交者在过去六个月内的活跃水平和贡献水平。
	- 跨模块的人员平衡。
	- 模块变更，如新增或弃用。
	- 供应商间的人员平衡。

在这种情况下：
- 需要通过 PR 将相关人员从提交者条目移动到 MAINTAINERS.md 的退休条目。相关人员必须在 PR 的正文中提及。这作为最后的联系尝试，以便他们提供反馈。
- 从 cubefs.groups.io/g/maintainers 邮件列表中移除他们。

## 路线图

### 规则
  - 确定目标：清晰阐明项目的长期和短期目标。这些目标应与项目的愿景和价值观保持一致，同时满足用户或社区的需求。
  - 优先级：根据重要性和紧迫性对目标进行排名。考虑资源和时间限制，确保重点放在最关键的目标上。
  - 时间规划：将目标分解为里程碑或阶段性任务。为每个阶段定义具体目标和可衡量指标，以便后续评估进展。
  - 透明和沟通：与项目利益相关者（包括用户、贡献者和其他相关方）公开分享路线图。这有助于建立透明度并使每个人都了解项目的方向和计划。
  - 持续调整：开源项目的路线图应是一个动态文档，可能需要随着新见解的获得进行调整和更新。定期回顾和重新评估路线图，并根据需要进行修改。
  - 方法：在制定路线图时，考虑社区的意见和建议，以确保项目的发展与广泛的期望和需求保持一致。
  - 与项目用户和贡献者进行讨论，以收集反馈并了解他们的需求。这可以通过邮件列表、论坛和社交媒体等渠道进行。

### 项目路线图的变更
- TSC 将通过内部会议或 maintainers@cubefs.groups.io 邮件小组收集维护者的所有提案。
- 项目路线图（ROADMAP.md）的变更应由 TSC 成员在 GitHub 上打开拉取请求发起。
- TSC 将根据多数票做出决定。
- 拉取请求应保持开放至少 2 周。

## 特别兴趣小组（SIG）
- 目前，CubeFS 正在逐步实施 [SIG 分组](https://github.com/cubefs/cubefs-community)。
- CubeFS 项目根据项目开发的需求建立特别兴趣小组（SIG）。

### 对 SIG 的期望
- 目标是实现分布式决策结构和代码所有权。
- 提供专门的论坛以完成工作、做出决策并引导新贡献者。
- 项目中每个可识别部分（如代码库、子目录、API、测试、问题、PR）都旨在由特定的 SIG 拥有。
- SIG 必须具有开放的成员资格政策，并始终在开放环境中运作。

### SIG 成员的期望
- SIG 主席：
	- 职责：
		- SIG 的组织者和倡导者，负责 SIG 的运作以及设定 SIG 的发展目标。
		- 与其他 SIG 和更广泛的社区沟通和协调。
	- 每个 SIG 至少必须有一个主席，同时最多可以有两个主席。
- 技术负责人：
	- 职责：技术负责人负责领导 SIG，以确保其技术协调，特别是在技术决策和执行方面。
	- SIG 可以有技术负责人，也可以没有，这取决于 SIG 的性质。
- 参与者（成员）：
	- 职责：积极贡献于 SIG，完成技术负责人分配的工作。

主席与技术负责人之间的关系：
- 主席负责 SIG 的目标和方向，以及设定长期计划和短期目标。
- 技术负责人负责实施目标和短期目标。
- 在发生争议时，问题可以提交给 TSC 进行决策。

### SIG 与其他组织或角色的关系
- 与 TSC 的关系：
	- SIG 遵循 TSC 的领导。
- 与维护者名单中的维护者的关系：
	- 如果 SIG 负责主要项目模块，则所有与该模块相关的维护者和提交者应包含在维护者名单中，以防止中断。
	- 维护者与 SIG 组之间的任何争议可以通过 TSC 解决。

### 成为 SIG 的成员
- **标准**：
	- 主席必须是维护者成员。这有助于减少有关 SIG 治理策略和整体社区治理的争议。
	- 技术负责人必须是维护者或提交者。
	- 参与者（成员）必须是可以积极贡献于 SIG 的贡献者。
- **提名**：
	- SIG 主席：
		- TSC 成员通过 maintainers@cubefs.groups.io 内部提名维护者，提名需经多数票批准，然后在 GitHub 上进行公开审查。
	- 技术负责人：
		- 根据 SIG 的整体规模，SIG 主席可以提名大约两到三个人来支持该小组的技术工作。
		- SIG 主席可以独立决定是否在其章程中包含技术负责人。
	- 参与者：
		- 无需提名，由主席或技术负责人直接添加。
- **选举**：
	- 当主席或技术负责人发生变更时，提名 PR 申请应由维护者提交，并经 TSC 批准。

### SIG 中的成员变更和管理
- 如果主席或技术负责人感到无法履行“对 SIG 的期望”，他们可以自愿辞职。
- TSC 将根据以下因素调整主席或技术负责人：
	- 在过去六个月内的活跃水平和贡献水平。
	- 供应商间的人员平衡。
- 如果参与者无法满足 SIG 的要求，主席或技术负责人可以通过在 SIG 中打开 PR 直接将其移除，并通知该参与者。

### SIG 生命周期

- **成立**：
   - 任何社区维护者和贡献者都可以提议创建一个 SIG。
   - 收集社区讨论和反馈。
   - 每个 SIG 由来自多个公司和组织的个人组成，他们在特定领域推动项目的共同目标。

- **审批**：
   - 提案由 TSC 审查，以确保其与项目目标一致，通过多数投票作出决策。
   - 如果获得批准，SIG 正式成立，可招募成员。

- **活跃阶段**：
   - SIG 定义其目标、职责和流程。
   - 招募成员并分配角色。
   - 定期召开会议和沟通，以促进协作。

- **评估**：
   - SIG 定期评估其进展和对项目的贡献。
   - 收集社区反馈以改进运作。

- **维护**：
   - SIG 继续致力于其目标，适应社区需求的变化。
   - 新成员可以加入，角色可根据需要进行调整。

- **关闭**：
   - 如果 SIG 不再需要或未能实现其目标，SIG 主席、技术领导和 TSC 成员可以提议关闭。
   - TSC 审查并批准关闭，确保任何正在进行工作的平稳过渡。

## 厂商中立性

- 社区最重要的Governance body，TSC、Maintainers、Committers，以及special group如PSC（security team），应该由来自不同公司的member组成，以保证中立性，默认为单一公司不超过50%。
- 社区的基础设施资源包括网站、slack、邮件列表等，都应该由社区的成员共同维护，避免被单一公司控制。
- 对于社区的交流讨论等信息，处于transparency的考虑，应该最大限度的公开，如果特殊信息在某个时间段不适合大范围公开，应该在TSC、PSC(security team)等多元化的group内共享，并且在合适的时候进行公开披露。
- 技术架构的中立型，社区在考虑技术方案时，不会采用绑定单一公司产品的技术方案，要考虑多provider 集成的可能性(灵活度)。

## GitHub 项目管理

__cubefs__ GitHub 项目的维护团队反映了维护者的名单。

## 子项目

CubeFS 的子项目与主项目密切相关，作为必要的补充，需要在必要时与主版本同步发布。在其他列出的项目中，有些用于探索性目的，而其他则与外围生态产品相关。

当前子项目：
- [CubeFS-Helm](https://github.com/cubefs/cubefs-helm)：CubeFS-Helm 项目帮助部署由 Kubernetes 编排的 CubeFS 集群。
- [CubeFS-CSI](https://github.com/cubefs/cubefs-csi)：CubeFS 容器存储接口 (CSI) 插件。
- [CubeFS-Dashboard](https://github.com/cubefs/cubefs-dashboard)：CubeFS 的网页管理工具。

CubeFS 组织欢迎接收新的子项目加入其范围。要接受一个项目进入 __CubeFS__ 组织，必须满足以下标准：

- 必须根据 Apache 许可证 v2.0 的条款进行许可。
- 必须与 CubeFS 生态系统的一个或多个范围紧密相关，并且被CubeFS依赖：
  - CubeFS 项目工件（网站、部署、CI 等）
  - 外部插件
  - 其他与存储相关的主题
- 必须由与子项目作者无关的维护者支持。
- 子项目可以拥有自己的代码库，但需遵循与主项目相同的治理机制。
- 加入外围项目需要在主项目中提交 issue，以获得 TSC 委员会的投票认可。同样，诸如项目归档等重大操作也需要经过 TSC 委员会的同意。

提交过程以 Pull Request 或 Issue 的形式开始，需在 [cubefs/cubefs](https://github.com/cubefs/cubefs) 仓库中提供上述所需信息。一旦项目被接受，便视为 __CubeFS__ 旗下的一个子项目。

## 外围项目

除了主项目 CubeFS 及其子项目，其他仓库内的项目作为外围项目存在。

CubeFS 组织欢迎在其框架下接收新的外围项目。要将一个项目纳入 __CubeFS__ 组织，必须满足以下标准：

- 必须在 Apache License v2.0 的条款下获得许可
- 必须与 CubeFS 生态系统的一个或多个范围相关
  - CubeFS 项目工件（网站、部署、CI 等）
  - 外部插件
  - 其他与存储相关的主题
- 子项目可以拥有自己的仓库，但需遵循与主项目相同的治理机制
- 加入外围项目需要在主项目中提交 issue，以获得 TSC 委员会的投票认可。同样，诸如项目归档等重大操作也需要经过 TSC 委员会的同意。

## 产品安全委员会 (PSC)

[产品安全委员会](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md#product-security-committee) 负责组织整个响应，包括内部沟通和外部披露，但需要相关开发人员和发布负责人提供帮助，以成功运行此过程。

## 贡献

[有关贡献CubeFS的详细信息](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md)

明确的角色及其晋升路径如下：
- [成为提交者](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-committer)
- [成为维护者](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-maintainer)
- [成为技术监督委员会成员](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-tsc-member)

## 新插件

CubeFS 欢迎接收作为 CubeFS 仓库一部分的新插件。提交过程与 Pull Request 提交相同。与小型 Pull Request 不同的是，新插件的提交应仅由与插件作者无关的维护者批准。

## CubeFS 与 CNCF

CubeFS 可能参与与 CNCF（或其他 CNCF 项目）相关的营销、活动或活动。任何维护者都可以帮助推动 CubeFS 的参与，只要她/他向 `maintainers@cubefs.groups.io` 发送电子邮件（或创建 GitHub Pull Request）以呼吁其他维护者参与。`呼吁参与` 应保持开放不少于一周的时间，若时间允许，或保持一个 _合理_ 的时间框架，以便维护者有机会自愿参与。

## 行为准则

[CubeFS 行为准则](CODE_OF_CONDUCT.md) 与 CNCF 行为准则保持一致。

## CNCF 联络官

- 联络官负责与 CNCF 的日常沟通，包括信息更新、需求沟通、社区活动会议等。
- 联络官必须是由 TSC 内部推荐的 TSC 成员。任期没有固定期限，可以在 TSC 成员变更时进行调整。