OpenHarmony跨平台框架社区SIG治理指南
概述
说明：OpenHarmony跨平台框架社区是OpenHarmony社区的子社区，本文档参考OpenHarmony社区SIG治理框架制定，在保持一致性的基础上，结合跨平台框架社区的特点进行适配。
SIG（Special Interest Group）是OpenHarmony跨平台框架社区中，由对特定技术领域充满热情的专家和贡献者组成的兴趣小组。每个SIG聚焦明确的技术方向，通过开放、透明的协作方式，推动该领域的技术演进、项目开发与生态维护。
SIG分类
垂直领域SIG：聚焦特定跨平台框架技术栈
- Flutter SIG、React Native SIG、Cordova SIG、Chromium SIG 等
横向领域SIG：提供跨领域支撑能力
- 开源能力SIG 等
治理原则
为保障SIG公开透明运作，建立明确的贡献者参与路径，各SIG需遵循以下核心原则：
- 章程明确：具备清晰的SIG章程，明确职责边界、治理结构与交付物标准
- 透明运作：定期召开公开会议，实行议题公开征集、会议开放参与、纪要归档可查
- 例会：定期召开公开会议，会议议程提前公布，会议纪要及时发布至邮件列表
- 邮件列表：作为官方沟通渠道，用于发布通知、讨论议题和归档决策
- 向PMC汇报：SIG Leader需定期向PMC汇报工作进展，接受社区监督和指导
- 平台协作：依托AtomGit平台进行开发协作，以Issue/PR形式公开管理需求与缺陷，确保及时响应
- 文档驱动：维护版本路标、架构设计、用户指南等关键文档，统一存放于SIG仓库
- 贡献友好：提供符合SIG特点的贡献指南，可基于社区通用指南细化
- 协同联动：主动与其他SIG、专项工作组建立协作机制，推动跨领域问题解决
SIG的创建、孵化与退出流程详见SIG生命周期管理。
组织架构
角色体系
SIG采用分层治理架构，关键角色定义与社区成员资格保持一致，包括：
- SIG Leader(s)：特别兴趣小组（SIG）的核心领导层，共同承担版本规划、SIG治理与技术决策的最终责任，通常由在该领域有深入专业知识和社区影响力，并在社区中有持续领导力贡献的专家担任，对SIG技术方向和团队管理负责
- Committer：SIG特定项目的技术权威和核心维护者，对项目健康度负有首要责任，在特定代码仓库拥有写权限，负责代码审查和质量把关，并参与技术决策和项目规划
- 专项代表：包括版本管理代表、测试代表、质量代表、法务代表、合规代表、安全代表等，分别在各自职责范围内为SIG提供支撑
角色任命：
- SIG初始角色在成立时由PMC任命
- 后续晋升遵循社区成员资格规定的准入标准和流程
通用要求
活跃度标准：长期请假需提前通知并授权委托人；未委托且连续1个月失联自动退出角色
晋升与退出：满足社区成员资格准入条件，经提名、评审、投票；可随时退出需协助寻找继任者；角色变更及时更新sigs.yaml
决策升级：项目级→Committer自主；SIG级重大→SIG Leader协调；跨SIG冲突/SIG Leader分歧→PMC裁决
关键角色
SIG Leader
SIG Leader作为特别兴趣小组（SIG）的核心领导层，共同承担版本规划、SIG治理与技术决策的最终责任。SIG Leader通常由在该领域有深入专业知识和卓越经验，并在社区中有持续领导力贡献的专家担任，对SIG技术方向和团队管理负责。
成员管理：≥2人，信息登记在sigs.yaml并保持更新
技术治理：制定技术愿景和路线图；跟踪维护版本管理并向PMC汇报；审批项目生命周期工作；参与重大技术方案设计和架构设计；解决跨项目/跨SIG技术问题
运营治理：召集主持例会，引导讨论决策；确保sigs.yaml和会议信息最新，会议录制公开；定期向PMC汇报进展；代表SIG与PMC及其他SIG沟通协调；推动SIG章程制定与变更；维护贡献指南（如需）；管理仓库权限和邮件列表；牵头编写年度报告
Committers
SIG Committer是SIG特定项目的技术权威和核心维护者，对该项目的健康度负有首要责任。Committer在特定代码仓库拥有写权限，负责代码审查和质量把关，并参与技术决策和项目规划。
成员管理：≥2人（每个SIG项目至少2名支持交叉检视），信息登记在sigs.yaml并保持更新
职责：参与技术方案设计讨论；协同SIG Leader维护版本管理和项目生命周期；高质量完成代码开发、提交和维护；积极参与Issue分类和PR评审；保障代码质量；指导培养新贡献者
晋升标准：参见社区成员资格
专项代表
各专项代表≥1人，信息登记在sigs.yaml并保持更新。
版本管理代表（Release Manager）：
负责特定版本的发布管理，协调版本开发、测试和发布全流程。制定版本计划和时间表，协调版本开发和测试，主持版本发布评审会议，执行版本发布流程，发布版本公告和文档。成员信息需在sigs.yaml中登记和更新，详见版本管理指南。
测试代表（Test Representative）：
负责确保SIG项目的测试质量和流程规范，保障软件交付质量。制定和维护测试策略和测试计划；执行版本测试阶段的质量门禁检查；审核和签发测试报告，为版本发布提供决策建议；参与版本规划评审和发布决策；协助开发者进行测试用例设计和代码质量改进；在sigs.yaml中登记和更新信息。
质量代表（Quality Representative）：
负责质量管理体系建设和质量标准制定，推动SIG项目质量持续改进。制定和维护质量标准、度量指标和验收准则；对版本候选进行全面质量评估；参与版本规划和发布决策，确保质量标准执行；在sigs.yaml中登记和更新信息。
法务代表（Legal Representative）：
负责确保SIG项目的法律合规性，管理知识产权和法律风险。确保项目知识产权归属清晰，管理专利、商标、版权；监督CLA和DCO的签署和执行；识别和评估项目法律风险，提供法律建议；协助处理知识产权争议、许可证冲突等法律问题；维护项目法律文档；参与版本发布前的法律合规审查和重大决策的法律风险评估；在sigs.yaml中登记和更新信息。
合规代表（Compliance Representative）：
负责确保SIG项目符合开源许可证、安全规范和行业标准等合规要求。确保项目及依赖项的开源许可证合规，管理LICENSE和NOTICE文件；建立和维护许可证自动化扫描机制；审查第三方依赖的引入和更新，确保许可证兼容性；建立和完善开源合规流程；协调安全扫描、漏洞修复等安全合规工作；参与代码审查、版本发布前的合规审核和依赖升级评审；在sigs.yaml中登记和更新信息。
安全代表（Security Representative）：
负责SIG项目的安全管理和安全风险控制，确保项目符合安全标准和最佳实践。制定和维护安全策略、安全标准和安全检查清单；建立和完善安全扫描、漏洞检测等自动化安全检查机制；负责安全漏洞的识别、评估、修复和披露流程管理；审查代码中的安全风险，参与安全相关的代码审查；协调安全事件响应，建立安全应急预案；参与版本发布前的安全审核和重大架构变更的安全评估；推动安全培训和安全意识提升；在sigs.yaml中登记和更新信息。
SIG运营机制
会议管理
SIG定期召开公开会议（线上或线下），对所有社区成员开放。召集人提前通知会议时间、地点和议程，会后发布纪要并归档到meetings文件夹。
决策机制
SIG决策遵循“共识优先”原则，通过会议讨论、投票达成共识。若无法达成共识，由SIG Leader根据讨论做出决策；若SIG Leader无法达成一致或涉及跨SIG争议，申请PMC最终决策。
投票规则
投票权：SIG Leader、Committer及各专项代表在其职责范围内拥有投票权；同一组织仅一票，指定参会人员行使
决策分层：
- 日常决策：Committer自主决定（技术实现、代码审查等）
- 重要决策：Committer过半表决通过（架构变更、版本规划、资源分配、项目孵化毕业、章程非实质性修改、Committer及专项代表任免等）
- 关键决策：Committer 2/3表决通过（SIG Leader任免、章程实质性修改、SIG重组/合并/分拆、重大合作协议、年度战略规划等）
- 最高决策：SIG Leader 与 2/3 Committer表决通过（SIG终止/解散、社区治理制度变更建议等）
会议要求：半数以上有投票权的成员（含委托）出席方能召开；委托需书面授权并明确范围；投票决策需形成书面记录并公开
争议解决：项目级→Committer讨论→SIG Leader决策；SIG内角色分歧→SIG Leader协调；SIG Leader分歧→投票或PMC裁决；跨SIG争议→SIG Leader协商或PMC裁决
本文档将根据社区实践和OpenHarmony社区规则变化持续更新和完善。如有任何疑问或建议，欢迎通过Issue或PR提出。