# SIG治理 对SIG进行标准化治理的目标是，让每个SIG都能保持透明度，并且能够让贡献者找到适合的SIG。因此，所有的SIG都应遵循以下的准则： - 经过SIG章程指南批准成立。 - 定期会议：每个月至少30分钟。（6月和12月除外） - 保留会议记录，并提交到Community仓库内。 - 录制会议，并在DragonOS开源社区的bilibli官方账号上公开播放 - 记录活动并完成年度报告 - 确保相关工作在项目拥有的 GitHub 组织和存储库中进行，代码和测试由 SIG 明确拥有和支持，包括问题分类、PR 审查、测试失败响应、错误修复等。 - 使用[提供的论坛]作为工作、沟通和协作的主要方式，而不是私人电子邮件和会议。 - 如果SIG的贡献指南与DragonOS社区的一般贡献指南有出入，请确保在 DragonOS-Community/community存储库中的 SIGs 文件夹中定义贡献说明 (CONTRIBUTING.md)。 - 帮助和赞助 SIG 有兴趣投资的工作组 ## 角色 ### 关于角色的说明 在本节中，“负责人”指的是担任主席、技术负责人或子项目负责人角色之一的社区成员。负责人可能担任多个角色，而且常常是这样。 任何 DragonOS社区小组都没有单一的负责人。负责人对小组的一部分有特定的决策权，因此也有额外的责任。每个角色的具体说明如下。 初始角色在 SIG 或子项目成立时作为接受该 SIG 或子项目的一部分而定义。 ### 负责人 #### 活动期望 - 负责人应保持在其角色中的活跃和响应性。 - 如果负责人计划休假1个月或更长时间，应与其他负责人协调，以确保休假期间角色得到充分的人员支持。 - 休假1-3个月的负责人可以与其他负责人合作，确定一名临时替代者。 - 负责人应移除任何未通知休假且一个月以上无法联系或一个月以上未履行其文档职责的其他负责人。 - 移除可以通过活跃负责人的**绝对多数**投票来实现。 - 如果没有足够的*活跃*负责人，那么剩余的活跃主席、技术负责人和子项目负责人之间的**绝对多数**投票可以决定移除负责人。 #### 要求 - 负责人必须是至少是[我们贡献者列表上定义的"成员"]，才有资格在 SIG 中担任领导角色。 - SIG 可能会根据角色的不同，要求对应的负责人具有相关领域的知识。这些要求应当以文本形式记录下来。 - 对人员管理感兴趣，并且有相应的管理技能。 #### 向上反馈 - 负责人成员资格的争议可以向上反馈到 SIG 主席。SIG 主席成员资格的争议可以向上反馈到项目管理委员会(PMC)。 #### 负责人的入职和离职 - 负责人可以随时决定卸任并提出替代者。在其他负责人中使用懒人共识，以多数票作为后备来接受提案。候选人应得到 SIG 贡献者或子项目贡献者（如适用）的多数支持。 - 负责人可以通过负责人之间的**绝对多数**投票选择额外的负责人。这应得到 SIG 贡献者或子项目贡献者（如适用）的多数支持。 #### 所有负责人 - 应该维护他们的 SIG 或子项目的健康 - 应该至少对一个子项目或整个 SIG 显示持续的贡献。 - 应该在 SIG 和/或至少一个子项目中持有一些文档化的角色或责任（例如审阅者、批准者等） - 可以为子项目构建新功能 - 可以参与他们担任角色的子项目的决策 #### 主席 - 数量：2人或以上 - 成员资格在 **SIG的README文件** 中记录 - 应定义如何管理优先级和承诺。可以根据需要委派给其他负责人。 - 应推动宪章变更（包括创建）以获得社区的认同，但可以将内容创建委派给 SIG 贡献者。 - 必须与子项目负责人共同识别、跟踪和维护 SIG 在当前版本的DragonOS中的变更（比如改进了什么功能，修了什么bug）的列表。但可以委派给其他贡献者来履行这些职责。 - 可以将 SIG 路线图的创建委派给其他负责人。 - 必须组织主要小组会议并确保 **SIG的README文件** 保持最新，包括子项目及其会议信息，但应将子项目会议的需要委派给子项目负责人。 - 应促进会议，但可以委派给其他负责人或未来的主席/培训中的主席。 - 如果贡献者体验或入职知识与通用 [贡献者指南] 中的不同，必须在适当的 SIG 文件夹中确保有一个维护的 CONTRIBUTING.md 文档。可以委派给贡献者来创建或更新。 - 必须确保会议被记录并可供查看。 - 必须协调与其他社区小组如 SIGs 和项目管理委员会的沟通，并成为连接者，但可以在适当的情况下将实际沟通和内容创建委派给其他贡献者。 - 必须创建SIG的年度 [年度报告]，但应从其他 SIG 参与者那里获得帮助以便进行策划。 #### 子项目Maintainer 子项目Maintainer是 DragonOS 社区中子项目的技术权威。他们必须展现出对子项目健康的良好判断力和责任感。 - 数量：2人或以上 - 成员资格在 **SIG的README文件** 中记录，并限定在子项目范围内 - 必须为他们的子项目设定技术方向，直接或通过委派做出或批准设计决策 - 必须指导和培养批准者、审阅者和子项目的贡献者。 - 必须维护组件，审查，指导并批准增强子项目所拥有领域的提案 - 必须积极参与问题分类和审查 PR - 应该作为子项目中技术讨论和决策的升级点 - 应该设定里程碑优先级或委派此责任给其他负责人 - 应该确保有一个健康的讨论和决策流程。 - 可以做出决策以解决冲突 ## 子项目 ### 子项目创建 子项目可以通过 SIG 技术负责人的简单多数投票创建。 - SIG的`README.md`必须更新，以把子项目信息囊括在里面。 - 如果子项目的流程与 SIG 治理不同，则必须有一个文档来记录差异。例如，如果子项目单独发布 - 它们必须记录发布和规划是如何执行的 ### 子项目的要求 子项目大致分为两类，一类是DragonOS kernel本身以及与其关联性较强的部分，称为DragonOS核心子项目；另一类则是与DragonOS kernel发布周期不直接关联的部分，称为DragonOS周边子项目。 影响 SIG 中多个子项目的问题应由 SIG 的负责人或各个子项目负责人联合解决。 ## SIG 的撤销 如果 SIG 无法达到SIG治理规范规定的人数或无法履行其组织管理职责： - 在 3 个月或更长时间后，它 **应该** 被撤销 - 在 6 个月或更长时间后，它 **必须** 被撤销 [我们贡献者列表上定义的"成员"]: /governance/community-membership.md [提供的论坛]: /communication/README.md [贡献者指南]: /contributors/README.md [年度报告]: /governance/annual-reports.md