community-master.zip

# SIG管理章程 简体中文 | [English](./README-EN.md) # OpenHarmony社区SIG管理制度 本文档主要介绍OpenHarmony社区SIG（Special Interest Group）的管理制度，包括申请新SIG和SIG的运营、变更及终止。 ## 一、申请新SIG ### 1.申请准备 - 开发者需仔细阅读[SIG管理制度]，了解OpenHarmony社区SIG的运作规则，提前准备好下文所述的SIG章程、SIG制度等文档； - 开发者可通过[OpenHarmony zulip相关频道](https://zulip.openharmony.cn/join/u7vafdcbyia32bsssygwbbee/)提前告知社区新建SIG的意向，寻找兴趣相投的开发者共同参与； - 申请新SIG需确认其技术方向的唯一性与可行性： - OpenHarmony社区每个SIG孵化的技术方向都不同，发起的申请如果属于OpenHarmony社区已有的技术方向，则会被建议直接参与相关SIG共建； - 开发者可查看OpenHarmony社区[已有SIG列表](https://gitee.com/openharmony/community/tree/master/sig)，同时查看[历史DEV邮件列表](https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/)，以确认没有相同技术方向的SIG存在或处于申请中； - 申请成立SIG的技术项目应能够最终转化为OpenHarmony的新增部件； - 如查阅相关信息后仍对技术方向问题存有疑虑，开发者可通过邮件列表dev@openharmony.io咨询PMC。 ### 2.提交申请 SIG发起人参照[SIG章程模板]创建SIG提案初稿，以附件形式发送给dev@openharmony.io，邮件标题为： - **SIG-Charter-Proposal-SIG XXX+简要介绍**，如`SIG-Charter-Proposal-SIG Test+OpenHarmony开发自测试能力构建`。 ### 3.PMC评审提案 - SIG发起人接受PMC问询，对SIG提案进行必要的说明，并根据PMC的指导意见修改提案，通过原申请邮件与PMC进行沟通，直至PMC无疑问； - 初审过程中，SIG提案可能会因为不符合OpenHarmony社区整体技术规划或已有相关技术方向的SIG存在而被拒绝； - 收到PMC邮件回复同意后代表初审通过，SIG可发起人[申报PMC例行会议新建SIG议题](https://etherpad.openharmony.cn/p/pmc)，按时接入PMC会议，介绍待新建的SIG，并请PMC批准SIG成立以及相关SIG仓库和沟通渠道的建立； - 评审会议形成会议纪要并附PMC评审意见。 ### 4.提交PR SIG发起人收到PMC评审反馈、确认SIG提案通过后，执行以下操作： - fork OpenHarmony社区仓库到本地，在`OpenHarmony/community/sig`仓库内新建SIG文件夹，文件夹名称为“sig-XXX”； - 创建该SIG的`README.md`、`OWNERS.md`文档，文档格式请参考[其他SIG](https://gitee.com/openharmony/community/tree/master/sig)，如sig-driver的[README.md](https://gitee.com/openharmony/community/blob/master/sig/sig-driver/sig_driver_cn.md)及[OWNERS.md](https://gitee.com/openharmony/community/blob/master/sig/sig-driver/OWNERS)。 - 更新`sigs.json`文档，参考以下样例： **sigs.json 文件格式** | 字段 | 说明 | |:---|:---| | sig-name | SIG名称 | | projects| gitee仓名 | | project-path | OpenHarmony下的归档路径，若不涉及回合OpenHarmony填写NONE | **sigs.json 样例** ``` "sigs-List":[ { "sig-name":"sig-python", "projects":"https://gitee.com/openharmony-sig/python", "project-path":"python/" }, { "sig-name ":"sig-updates", "projects":["https://gitee.com/openharmony/startup_appspawn_lite", "https://gitee.com/openharmony/startup_bootstrap_lite"] "project-path":["base/startup/appspawn_lite", "base/startup/bootstrap_lite"] }, ] } ``` 完成上述文档创建、更新后，SIG发起人提交一个Pull Request（PR），请求将以上更新合入主干，PR中附PMC评审意见等相关资料。 该PR由Community仓的Committer审核通过后，相关更改被合并至Community仓，新SIG成立。 ## 二、SIG运营 ### （一）SIG仓库及沟通渠道 1. SIG使用社区统一基础设施开展工作和交流，包括Gitee仓库和邮件列表。 2. 新SIG负责人在[OpenHarmony/community仓库](https://gitee.com/openharmony/community)提交Issue，申请为该SIG新建仓库及邮件列表。 3. Issue中应注明仓库路径、邮件列表名称以及新SIG的Leader和Committer，并附[前述PMC评审意见](#3.PMC评审提案)，通过在Issue中[@wanchengzhen](https://gitee.com/wanchengzhen)或[@im-off-this-week](https://gitee.com/im-off-this-week)通知Sig Architecture评审。 4. Sig Architecture评审通过后： - SIG负责人联系[社区代码仓管理员](https://gitee.com/landwind)执行建仓操作； - SIG邮件列表负责人联系 **likang@openatom.org** 创建邮件列表： - 需详细说明邮件列表名称和管理员邮箱（一般为SIG负责人）， - 邮件列表创建成功后，SIG负责人进入[OpenHarmony项目群邮件列表登陆页面](https://lists.openatom.io)，通过管理员邮箱登录后可管理邮件列表（批准成员加入或审核邮件等），其他人可订阅查看。 5. SIG可根据需要自行组建微信群等其他社交群组。 ### （二）完善SIG制度文档 1. SIG章程与制度文档需遵循OpenHarmony社区章程与相关制度。 2. 每个SIG至少要有`README.md`、`OWNERS.md`二个文档，详细说明SIG的工作范围、工作目标、成员、沟通方式、决策机制、例行会议时间、如何参与贡献等，且需要PMC批准。 3. SIG如有特殊贡献文档，需遵循[OpenHarmony社区贡献原则](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/Readme-CN.md)。 ### （三）SIG成员及职责 SIG的主要成员是Leader和Committer，每个SIG初始成员不少于3人。 `README.md`、`OWNERS.md`文档中需详细列出SIG Leader和Committer。SIG Leader和Committer的更换及任命需PMC批准。SIG可根据需要增加其他岗位角色，但需PMC批准。 #### **1.Leader** 每个SIG至少有1名Leader。 作为SIG组的管理者，Leader负责SIG的运营及维护，同时直接参与上游或周边组织的协调。 初始Leader由SIG创建时指定，后继人选从Committer中选出。 如SIG组内暂无Committer或人数较少，Committer的职责由Leader兼任。SIG Leader拥有SIG子领域的代码仓管理员权限。 **主要职责：** - 定义SIG的工作范围及业务目标。 - 确定SIG的技术路线：包括规划和决策SIG技术方向、路标规划、架构演进。 - 吸纳并发展Committer参与SIG的项目孵化、文档完善及社区推广。 - 定期在PMC会议中汇报SIG孵化项目及SIG运营进展，并基于PMC的指导建议完成相关改进。 - 召集SIG组会议：定期召集SIG组会议，决策SIG组内上升的争议。 - 参与社区协调活动：作为SIG的代表参与社区活动和特定会议。 #### **2.Committer** 每个SIG至少有2名Committer。 初始Committer由SIG创建时指定，后继人选从社区Contributor中选出，由Leader和Committer提名、SIG当前贡献者全体投票表决产生。 Committer负责代码审核、主干代码合入及特性设计方案审核和批准，拥有SIG子领域的代码仓写入权限。 **主要职责：** - 处理SIG内及社区与本SIG相关的Issue、PR、邮件列表问题等。 - 辅导Contributor快速理解SIG领域架构设计并提升代码开发技能。 - 跟踪依赖性问题：修复因代码更新导致的本SIG内被破坏的依赖关系。 - 对本SIG内的安全问题进行分类和处理，参与安全团队的安全问题，维护SIG组内的安全规范和要求。 ### （四）SIG治理 #### 1.会议组织 - SIG需定期召开例行会议，每双周至少半小时，由SIG Leader主持； - 会议议程提前在邮件列表及官网进行公布； - 会议纪要及时发布并保存在`OpenHarmony/community/sig/sig-XXX/meeting-minutes`内。 #### 2.社区共建 - SIG Leader至少两个月一次，在PMC例会汇报SIG工作进展，并基于PMC指导意见改进工作； - SIG每年至少一次，由SIG Leader向社区报告SIG年度工作进展； - 协助