CubeFS 社区遵循以下原则：
- 开放：CubeFS 是开源的。
- 欢迎和尊重：参见行为准则。
- 透明和可访问：CubeFS 组织、CubeFS 代码库和 CNCF 相关活动（如级别、参与等）的变更均在公开场合进行。
- 贡献：根据想法和贡献的技术价值及其与项目目标、范围和设计原则的对齐程度接受想法和贡献。
CubeFS 项目有一个指导委员会。
- 指导委员会成员的任期为一年，个人可以连续多次担任此角色。
- 指导委员会成员负责项目的顶层设计、路线图的制定和社区管理。
- 指导委员会成员由来自独立开发者或供应商的核心维护者组成。
- 为确保公平，将努力保持不同供应商人员之间的平衡代表性。
- 单一供应商的人员不得超过总人数的50%。
- 指导委员会的任期为一年
每个人都要努力...
让社区运作需要每个人的投入和努力。维护者应积极参与拉取请求（Pull Request）的审查。维护者应在合理的时间内对分配的拉取请求做出回应，提供见解或将拉取请求分配给其他维护者。 每个维护者都列在顶层的MAINTAINERS文件中。
提交者是社区中的活跃贡献者，通过贡献代码、文档、参与社区讨论或回答社区问题等方式不断为社区做出贡献。
通常，他们需要对项目有良好的理解，以帮助更多的社区用户快速加入项目。提交者将负责审查相关问题或拉取请求，他们的意见对社区也非常重要。
每个提交者都列在顶层的MAINTAINERS文件中。
如果您有兴趣成为提交者，请发送电子邮件至 [email protected] 或打开一个拉取请求，并列出您的贡献。指导委员会将通过多数票审查提案，审查通过后，您将收到来自社区的邀请函。
成功合并重要的拉取请求或做出重大贡献后，任何现任维护者都可以联系拉取请求的作者，询问他们是否愿意成为 CubeFS 的维护者。维护者有权提名新的维护者，可以通过发送电子邮件至 [email protected] 或打开一个拉取请求。通常，新维护者从提交者中选出。指导委员会将通过多数票审查提案，审查通过后，您将收到来自社区的邀请函。
如果维护者认为自己无法履行“维护者的期望”，他们可以自由卸任。指导委员会将根据以下因素调整维护者名单：
- 维护者在过去六个月的活动水平和贡献水平。
- 各模块人员的平衡。
- 模块变更，如增加或废弃。
- 各供应商人员的平衡。
在这种情况下：
需要提交一个 PR 将相关人员从维护者条目移动到相应 OWNERS 文件的退休条目中。在 PR 正文中必须提到相关人员。这作为最后一次联系尝试，以便他们可以提供反馈。
仅适用于失去其身份的核心维护者： 从核心维护者团队中删除他们； 前往 https://maintainers.cncf.io/ 并打开一个 PR 将他们从 CubeFS 下删除； 从 cubefs.groups.io/g/maintainers 邮件列表中删除他们。
指导委员会成员的变更通过打开一个 GitHub PR 发起。
CubeFS 的任何维护者都可以对 PR 投票，投票可以是 +1 或 -1。
只有以下投票是有约束力的：
- 在 PR 打开前，已列在顶层MAINTAINERS文件中的任何维护者。
- 任何组织的维护者可以为该组织投票。但是，任何组织的有约束力投票数量不得超过维护者总数的1/2。
PR 不应早于任期结束前4周打开。 PR 应保持开放不少于 2 周。PR 只能在上一个任期结束后合并，并且需要在约束性投票中获得比 -1 更多的 +1 票。
当关于指导委员会变更的 PR 存在冲突时，拥有最多约束性 +1 票的 PR 将被合并。
指导委员会成员可以自愿卸任。
- 项目治理（GOVERNANCE.md）的变更可以通过打开一个 GitHub PR 发起。
- CubeFS 指导委员会的任何成员都可以对 PR 投票，投票可以是 +1 或 -1。
- PR 应保持开放不少于 2 周。
- 定义目标：清晰阐明项目的长期和短期目标。这些目标应与项目的愿景和价值观保持一致，同时满足用户或社区的需求。
- 优先排序：根据目标的重要性和紧迫性进行排序。考虑资源和时间限制，确保重点放在最关键的目标上。
- 基于时间的规划：将目标分解为里程碑或阶段任务。为每个阶段定义具体目标和可衡量的指标，以便稍后评估进展。
- 透明和沟通：与项目利益相关者（包括用户、贡献者和其他相关方）公开分享路线图。这有助于建立透明度，并使每个人都了解项目的方向和计划。
- 持续调整：开源项目的路线图应是一个动态文件，随着新见解的获得，可能需要进行调整和更新。定期审查和重新评估路线图，并根据需要进行修改。
- 方法：在创建路线图时，考虑社区的意见和建议，以确保项目的发展符合广泛的期望和需求。
- 与项目用户和贡献者进行讨论，收集反馈并了解他们的需求。这可以通过邮件列表、论坛和社交媒体等渠道进行。
- 项目路线图（ROADMAP.md）的变更可以通过打开一个 GitHub PR 发起。
- CubeFS 维护者的任何成员都可以对 PR 投票，投票可以是 +1 或 -1。
- PR 应保持开放不少于 2 周。
-
CubeFS 项目根据项目发展的需要设立特别兴趣小组（SIG）。每个 SIG 由来自多家公司和组织的个人组成，他们在特定领域内共同推进项目的发展。SIG 是永久性的，除非由技术指导委员会（TSC）解散。
-
目标是实现分布式决策结构和代码所有权，并提供一个专门的论坛来完成工作、做出决策和引导新贡献者。项目的每个可识别部分（如代码库、子目录、API、测试、问题、PR）都旨在由特定的 SIG 负责。 SIG 必须有开放的成员政策，并始终在开放环境中运作。SIG 领导层的变更（SIG 主席和技术负责人）需要技术指导委员会的批准，并且可以有不同的任期。
-
SIG 主席： 每个 SIG 必须至少有一名 SIG 主席，同时最多可以有两名主席。SIG 主席是组织者和倡导者，负责 SIG 的运作，以及与其他 SIG 和更广泛社区的沟通和协调。
-
技术负责人： 技术负责人负责引导 SIG 与其技术协作。这种协作包括 SIG 内部的协调和整个项目的外部协调。
- SIG 可以自主决定是否在其章程中包括技术负责人。根据 SIG 的整体规模，SIG 主席可以提名大约两到三名个人来支持小组的技术方面。为了履行其职责，技术负责人应具有与主席相同的权力，但在有争议时需要申请主席的意见。
- 对应模块的维护者需要成为相应 SIG 小组的一部分。目前，我们正在逐步实施 SIG 分组。维护者仍然对其负责的模块拥有完全的权力。维护者与 SIG 小组之间的任何争议可以通过 TSC（技术指导委员会）解决。
- 主席必须是维护者成员。这有助于减少关于 SIG 治理策略和整体社区治理的争议。
- PR 申请应由维护者提交，并在主席或技术负责人变更后由 TSC 批准。
- SIG 的内部管理可以由 SIG 主席根据 SIG 自身制定的规则决定。
- 供应商共享社区的沟通渠道，如社交媒体和消息平台。
- 鼓励参与项目的所有供应商积极参与公共活动的主题选择过程。
- 供应商可以申请参加开源会议和活动。邀请函应抄送至
[email protected]。 - 指导委员会将审查申请，如果批准，指导委员会可以在此事上提供指导。
决策建立在维护者之间的共识基础上。
提案和想法可以通过 GitHub 问题或 PR 提交以供同意，或者通过发送电子邮件至 [email protected]。
通常，我们更倾向于技术问题和维护者成员资格在相关人员之间友好解决。 如果争议无法自行决定，请寻找第三方维护者（例如，对问题有一些背景但未参与冲突的共同联系人）进行调解。 如果争议仍无法决定，指导委员会可以通过多数票做出决定。
决策过程应透明，以遵循 CubeFS 项目的原则。
所有提案、想法和由维护者或指导委员会做出的决定应成为 GitHub 问题或 PR 的一部分，或发送至 [email protected]。
cubefs GitHub 项目的维护者团队反映了维护者的名单。
CubeFS 组织欢迎新的子项目加入其旗下。要接受一个项目加入 CubeFS 组织，它必须满足以下标准：
- 必须根据 Apache License v2.0 的条款进行许可。
- 必须与 CubeFS 生态系统的一个或多个范围相关：
- CubeFS 项目工件（网站、部署、CI 等）
- 外部插件
- 其他存储相关主题
- 必须得到与子项目作者无关或无隶属关系的维护者的支持。
提交过程从在 cubefs/cubefs 仓库上创建拉取请求或问题并提供上述所需信息开始。一旦项目被接受，它将被视为 CubeFS 旗下的子项目。
CubeFS 欢迎作为 CubeFS 仓库一部分的新插件。提交过程与拉取请求提交相同。然而，与小型拉取请求不同，新插件提交应仅由与插件作者无关或无隶属关系的维护者批准。
CubeFS 可能参与 CNCF（或其他 CNCF 项目）相关的市场营销、活动或活动。任何维护者都可以帮助推动 CubeFS 的参与，只要她/他发送电子邮件至 [email protected]（或创建 GitHub 拉取请求）以呼吁其他维护者参与。如果时间允许，“参与呼吁”应保持开放不少于一周，或者保持合理的时间框架，以允许维护者有机会自愿参与。
CubeFS 行为准则与 CNCF 行为准则保持一致。
联络员负责与 CNCF 的日常沟通，包括信息更新、需求沟通、社区活动会议等。