Skip to content

Latest commit

 

History

History
executable file
·
318 lines (237 loc) · 17.9 KB

GOVERNANCE_CN.md

File metadata and controls

executable file
·
318 lines (237 loc) · 17.9 KB
Raw

CubeFS 治理

原则

CubeFS 社区遵循以下原则：

  • 开放：CubeFS 是开源的。
  • 欢迎和尊重：请参阅 行为准则。
  • 透明和可访问：对 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 文件中列出的任何维护者。
      • 任何组织的维护者可以为该组织投票。然而，任何组织的有效投票不得超过总维护者数量的 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 文件中。

维护者的结构

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

成为维护者

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

维护者身份的变更

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

在这种情况下：

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

对提交者的期望

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

Committers的结构

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

成为提交者

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

提交者身份的变更

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

在这种情况下：

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

路线图

规则

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

项目路线图的变更

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

特别兴趣小组（SIG）

  • 目前，CubeFS 正在逐步实施 SIG 分组。
  • 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 成员通过 [email protected] 内部提名维护者，提名需经多数票批准，然后在 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：CubeFS-Helm 项目帮助部署由 Kubernetes 编排的 CubeFS 集群。
  • CubeFS-CSI：CubeFS 容器存储接口 (CSI) 插件。
  • CubeFS-Dashboard：CubeFS 的网页管理工具。

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

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

提交过程以 Pull Request 或 Issue 的形式开始，需在 cubefs/cubefs 仓库中提供上述所需信息。一旦项目被接受，便视为 CubeFS 旗下的一个子项目。

外围项目

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

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

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

产品安全委员会 (PSC)

产品安全委员会 负责组织整个响应，包括内部沟通和外部披露，但需要相关开发人员和发布负责人提供帮助，以成功运行此过程。

贡献

有关贡献CubeFS的详细信息

明确的角色及其晋升路径如下：

新插件

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

CubeFS 与 CNCF

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

行为准则

CubeFS 行为准则 与 CNCF 行为准则保持一致。

CNCF 联络官

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