SIG角色和组织治理

​ 该Charter内容遵循openEuler宪章 README中描述的约定，本文会根据需要进行更新，以满足openEuler SIG的需求。

​ 为了使SIG的工作标准化，提高社区透明度，并将贡献者合理地引入到对应的SIG组内，SIG应该遵循以下准则：

• 创建章程并根据README进行申请
• 定期开会，建议每周至少30分钟
• 持续保存最新的会议备忘录，并保存在对应的文件夹
• 每季度至少在社区每周一次的会议中报告一次SIG的活动，集成类SIG可以调整成一年。
• 根据需要参与发行计划会议、回顾会议和燃尽会议等
• 确保在SIG拥有的Gitee组织和存储库内开展相关工作，以支撑社区内的编码和测试，包括问题分类、PR审核、问题响应、错误修复等。
• 采用社区提供的邮件列表、IRC等主要方式用于社区工作、沟通和合作,而不是私人邮件和会议。

社区角色

角色说明

本节中的“成员”是指

• 初始成员是在SIG或子项目成立时定义的，是接受该SIG或其子项目的一部分
• 成员应保持活跃并积极响应自己的角色职责
• 成员必须是社区成员，才有资格在SIG组中担任领导角色
• 休假超过1个月或更长时间的成员应该协调其他成员，以确保在休假期间为该角色配备足够的人员
• 休假1-3个月的会议可以与其他会员合作，以确定临时的替补成员
• 成员应删除未告知休假但超过一个月无法联系或超过一个月未履行其职责的任何其他成员。删除过程可以通过超级多数投票来完成；如果没有足够的活跃成员来获得超级多数的投票，则可以通过Maintainer，Committer和SIG所有者之间的超级多数来投票罢免。
• 如果对于成员有资格分歧，可以上升到Maintainer。如果对于SIG的Maintainer的资格的分歧可以上升到技术委员会。
• 成员可以决定随时退出并提议候选人，候选人应得到大多数SIG组成员的支持。
• 成员可以通过成员之间的多数投票选择其他成员。

Maintainer：

人数：1~3人 工作职责：SIG组的管理者，软件包的维护者。直接参与和技术委员会以及上游或周边的协调，但无汇报关系。初始由SIG创建时指定，后继人选从Committer中选出。如SIG组内暂无Committer或人数较少，Committer的职责可以由Maintainer兼任。

• 确定SIG的技术路线：包括规划和决策SIG技术方向、路标规划、架构演进。
• 制定SIG的项目发布计划：确定SIG的关键需求和发布计划；参与社区的PM活动，并协调SIG计划和社区版本的里程碑时间表匹配
• 参与社区协调活动：作为SIG的代表参与openEuler技术委员会或理事会组织的活动和特定会议等
• 召集SIG组会议：定期召集SIG组会议，决策SIG组内上升的争议

角色配置：openeuler.yaml内的developer标签

Committer

可选角色 人数：2~8人 工作职责：特性设计方案审核和批准，代码审核及主干代码合入。Committer由Maintainer/Committer提名并由当前的Contributor全体投票表决产生。

• 评审PR：对Contributor提交的PR完成评审，评审可以参考社区的编程建议和安全编程规范。
• 分发处理问题，请参考“问题处理流程“。
• 跟踪依赖性问题：在开发分支中，其他SIG组的软件包的更新可能会到导致破坏本SIG内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。
• 如有接口变更，通知可能会影响到的SIG：其他SIG或团队会依赖本SIG，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG。具体请参考接口变更通知流程。
• 更新和维护软件包版本：遵守社区的软件包更新质量控制策略完成软件包的更新。
• 和上游社区合作，包括：
  • 将所有变更推送到上游社区
  • 参与上游社区邮件列表
  • 获取上游社区的bug跟踪器的账户，并跟踪上游社区的重要bug
• 将严重的错误转发给上游社区以寻求帮助 更多信息，请参考“上游社区软件包管理建议”
• 和测试团队合作，包括：
  • 在提交软件包时，向质量检查人员提供如何调试/分类软件包的信息，以供问题的分类
  • 提供基本功能的测试用例，用于测试回归
  • 提交软件包更新时，提供有关更新中已经修复问题的测试用例，以供质量检查人员使用。

角色配置：openeuler.yaml内的developer标签

安全联络员

在committer中指定安全联络员 人数：1人 工作职责：

• 成为产品安全团队的对口SIG组联络人，对本SIG内的安全问题进行分类和处理。
• 参与安全团队的安全问题
• 维护SIG组内的安全规范和要求

组织管理

会议管理

• SIG组应至少每个月召集一次会议，会议由Maintainer主持（除非委托给特定成员），固定议程可以由SIG组内成员讨论确定
• 深入讨论技术委员会指定给本SIG组的——建议的技术和需求等，应由Maintainer组织（除非委托给特定成员）
• 定期更新社区会议

SIG组管理

• 确定本SIG组内的年度技术路线图和路标，并向社区PM发布
• 提供SIG组内版本的功能或需求清单
• 根据要求参加社区内的版本会议，提供和执行SIG计划

子项目管理

子项目可以由SIG的Maintainer或Committer提案创建，子项目可以通过SIG组内的Maintainer和Committer通过“懒惰的共识”（沉默即同意）评审接受，结果应得到大多数SIG组成员的支持。

• 提案创建者必须是子项目所有者
• openeuler.yaml必须更新为包含子SIG所有者的子项目信息和相关OWNER文件
• 所有子项目的治理和流程原则上与SIG相同，如有不同，必须在提案时说明。
• 如子项目发布的执行方式和里程碑的设置与SIG有差异，必须明确说明
• 子项目的组织管理可以和SIG合并，也可以单独运作。

技术流程

• 提出方案和决策请遵循决策流程
• 保证SIG组持续健康的测试 - 规范代码发布要求，如果可能可以合入到SIG组的构建中检查 - 通过构建保证引入的问题会通过测试自动检测并发送告警 - SIG组成员负责响应测试告警。如未能在24小时内修复，应该将破坏测试的PR回退 - 每次的SIG组会议应检查测试结果，成员应处理发现的错误，并在下次会议上反馈进展、
• 影响多个子项目的问题建议通过以下任意一种方式解决：
  • 方式一：SIG的Maintainer指定SIG的技术Leader仲裁或决策
  • 方式二：组织子项目的Maintainer联合会议

SIG退出

• 如果SIG无法定期组织一定的人数或无法履行组织管理职责 - 6个月以上的，应启动退出 - 12个月或更长时间的，必须退出