gian/cubefs
1
0
Fork 0
mirror of https://github.com/cubefs/cubefs.git synced 2026-08-02 02:00:56 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
2a041e7765
cubefs/GOVERNANCE_CN.md
leonrayang 2a041e7765 feat(docs): Update Governance related documentation 
1. Clarify the responsibilities of the TSC, maintainers, and committers.
2. Fix the issue in security reporting as incorrect email address for reporting vulnerabilities.
3. Clarify the governace of SIGs
4. Add a link to the governance section in README.md for emphasis.

Signed-off-by: leonrayang <chl696@sina.com>
2024-08-28 17:14:02 +08:00

16 KiB
Executable File
Raw Blame History

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 维护者。
  • 提名：维护者有权通过发送电子邮件至 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 分组。
  • 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 审查并批准关闭，确保任何正在进行工作的平稳过渡。

厂商中立性

  • 厂商共享社区的沟通渠道，例如社交媒体和消息平台。
  • 所有参与该项目的厂商都鼓励积极参与公开活动的主题选择过程。
  • 厂商可以申请参加开源会议和活动。邀请应抄送至 maintainers@cubefs.groups.io。
  • TSC 将审核申请，如果批准，TSC 可以提供指导。

GitHub 项目管理

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

子项目

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

当前子项目：

  • CubeFS-Helm：CubeFS-Helm 项目帮助部署由 Kubernetes 编排的 CubeFS 集群。
  • CubeFS-CSI：CubeFS 容器存储接口 (CSI) 插件。
  • CubeFS-Dashboard：CubeFS 的网页管理工具。

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

  • 必须根据 Apache 许可证 v2.0 的条款进行许可。
  • 必须与 CubeFS 生态系统的一个或多个范围相关：
    • CubeFS 项目工件（网站、部署、CI 等）
    • 外部插件
    • 其他与存储相关的主题
  • 必须由与子项目作者无关的维护者支持。
  • 子项目可以拥有自己的代码库，但需遵循与主项目相同的治理机制。

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

产品安全委员会 (PSC)

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

贡献

有关贡献CubeFS的详细信息

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

新插件

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

CubeFS 与 CNCF

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

行为准则

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

CNCF 联络官

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