SIG管理章程
简体中文 | English
OpenHarmony社区SIG管理制度
本文档主要介绍OpenHarmony社区SIG(Special Interest Group)的管理制度,包括申请新SIG和SIG的运营、变更及终止。
一、申请新SIG
1.申请准备
- 开发者需仔细阅读[SIG管理制度],了解OpenHarmony社区SIG的运作规则,提前准备好下文所述的SIG章程、SIG制度等文档;
- 开发者可通过OpenHarmony zulip相关频道提前告知社区新建SIG的意向,寻找兴趣相投的开发者共同参与;
- 申请新SIG需确认其技术方向的唯一性与可行性:
- OpenHarmony社区每个SIG孵化的技术方向都不同,发起的申请如果属于OpenHarmony社区已有的技术方向,则会被建议直接参与相关SIG共建;
- 开发者可查看OpenHarmony社区已有SIG列表,同时查看历史DEV邮件列表,以确认没有相同技术方向的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议题,按时接入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,如sig-driver的README.md及OWNERS.md。 - 更新
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仓库及沟通渠道
- SIG使用社区统一基础设施开展工作和交流,包括Gitee仓库和邮件列表。
- 新SIG负责人在OpenHarmony/community仓库提交Issue,申请为该SIG新建仓库及邮件列表。
- Issue中应注明仓库路径、邮件列表名称以及新SIG的Leader和Committer,并附前述PMC评审意见,通过在Issue中@wanchengzhen或@im-off-this-week通知Sig Architecture评审。
- Sig Architecture评审通过后:
- SIG负责人联系社区代码仓管理员执行建仓操作;
- SIG负责人联系邮件列表负责人创建邮件列表:
- 需详细说明邮件列表名称和管理员邮箱(一般为SIG负责人),
- 邮件列表创建成功后,SIG负责人进入OpenHarmony项目群邮件列表登陆页面,通过管理员邮箱登录后可管理邮件列表(批准成员加入或审核邮件等),其他人可订阅查看。
- SIG可根据需要自行组建微信群等其他社交群组。
(二)完善SIG制度文档
- SIG章程与制度文档需遵循OpenHarmony社区章程与相关制度。
- 每个SIG至少要有
README.md
、OWNERS.md
二个文档,详细说明SIG的工作范围、工作目标、成员、沟通方式、决策机制、例行会议时间、如何参与贡献等,且需要PMC批准。 - SIG如有特殊贡献文档,需遵循OpenHarmony社区贡献原则。
(三)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年度工作进展;
- 协助存在关联关系的周边SIG,联合完成临时性工作;
- 基于社区定期的SIG成果评估,表现优秀的SIG将被邀请参加社区版本发布会议。
3.技术决策
- SIG内的决策遵循OpenHarmony社区的治理模式。
- SIG内采用“懒惰共识”(沉默即同意)的方式进行决策:
- 如存在争议时,由包括Leader在内的全体Committer进行投票表决,以多数票通过的形式达成共识;
- 无法在SIG内达成共识时,可上升至PMC决策。
三、SIG变更
(一)增删项目或仓库
- SIG负责人在PMC例行会议中申报议题,接受PMC问询。
- PMC批准增删项目或仓库后,SIG负责人:
- 在
OpenHarmony/community
创建Issue请求SIG Architecture支持,完成新项目仓库的配置或删除仓库,Issue中附PMC评审意见; - 相关操作完成、Issue关闭后,更新
sigs.json
文档(参考上文),刷新README.md
; - 提交PR请求合并以上修改,PR中附PMC评审意见。
- Community仓的Committer合并PR,完成项目或仓库更新。
(二)修改SIG名称、章程、成员等
涉及SIG工作范围、成员变更等重大变更
- SIG负责人在PMC例行会议中申报议题,接受PMC问询。
- PMC批准变更后,SIG负责人:
- fork的
OpenHarmony/community/sig
的相关SIG文件夹内刷新README.md
、OWNERS.md
、等文档; - 提交PR,请求合并以上修改,PR中附PMC评审意见。
- Community仓的Committer审核并合并PR,确认变更。
SIG内的非重大变更
- SIG负责人:
- fork的
OpenHarmony/community/sig
文件夹下找到相关SIG文件夹,完成修改; - 刷新README.md等文档;
- 提交PR,请求合入以上修改。
- Community仓的Committer审核并合并PR,确认修改。
区分变更重大与否的标准可参考上文SIG的运营部分。
四、SIG终止
(一)以下情况将触发SIG终止申请:
- SIG已达到预期目标,无需再投入;
- SIG未达成预期目标,超过2个月不活跃;
- SIG违反OpenHarmony社区PMC或SIG制度;
- SIG Leader、Committer等成员流失,无法支撑SIG正常工作。
(二)SIG QA定期检查各SIG状态,并定期在PMC会议中汇报各SIG活跃度:
- 对于已达到预期目标的SIG,由SIG Leader通过邮件列表dev@openharmony.io提交SIG终止申请,PMC评估后进行终止操作。
- 对于未达到预期目标但不活跃的SIG,PMC委派PMC成员进入该SIG进行尽职调查,并组织SIG整改,整改时间2个月。SIG超过2个月依然不活跃时,由SIG Leader或QA-SIG Leader提交SIG终止申请,PMC评估后进行终止或合并操作。
(三)终止流程:
- 向dev@openharmony.io发送电子邮件,通知社区解散或合并SIG。
- SIG负责人在
OpenHarmony/Community
下创建一个PR,请求合并以下更改:
- 归档代码仓(归档地址)
- 删除SIG共享日历,确保已上传所有SIG会议回放及会议纪要(
OpenHarmony/Community/archive/sig-XXX/meeting-minutes
)。 - 将现有Community仓的SIG目录移至
OpenHarmony/Community/archive
文件夹内。 - 将SIG内每个子项目的所有权转让给项目外部的新SIG,或者直接废弃子项目;
- PMC决策合并SIG后,原SIG相关交付件由原SIG Leader按时按质交接给新SIG Leader,交接期为一个月。
- 停用或转移主仓库下的SIG仓。
- 停用或通过SIG-Testing转让SIG内所有测试基础设施作业。
- 删除或弃用SIG的所有标签。
- 删除或重命名任何引用该SIG的社区组织。
- 更新
sigs.json
文档。
SIG数据存放和管理方式
SIG信息记录统一归档在OpenHarmony/community仓库的sig目录内:
-
sig_xxx.md/sig_xxx_cn.md:包括SIG组工作目标和范围、SIG管理的repository及描述、SIG组织会议、SIG成员。
-
sigs.json:为了便于工具自动提取,其中SIG的maintainer/committer信息单独备份一份至OWNER文件内,每个SIG所维护的仓库名称列表/目录结构位于sigs.json文件中。
- OpenHarmony/community仓的sig目录下存在一个sigs.json文件,这个文件中管理从PMC看到的所有SIG的信息。
- sigs 由 PMC 修改和维护,新sig申请由对应的 maintainer 提交PR,经过PMC审视后合入。
- sig 独立目录下的sig_xxx_cn.md/sig_xxx.md 为 sig 的信息展示区。其中SIG基本信息需按模板留空,新建SIG时填写完整。
- sig 独立目录下的OWNER存放相应sig的maintainer。
-
代码的管理
-
代码在sig-manifest仓下统一管理。
-
需要各leader维护本组内对应仓的 .xml 文件。
-
多个单位参与,可向leader提出建仓需求,由leader向社区提建仓pr。
-
-
文档的管理
- 各sig组的公共文档(包括会议纪要、会议材料等)需放入sig-content 仓对应组的文件夹内。
- 与各sig组子任务密切相关的技术文档可放到任务对应的代码仓内。
-
任务进度
- 任务进度以在对应任务仓下提issue形式更新。
- 作为跟踪进度的issue需要打上特定的标签,标签暂定为 sig_taskprogress。
-
开源协议的选择
- 建议开发者使用Apache 2.0 开源协议。
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"]
},
]
}