From 50d952274c961e2f09a4400b07b40e03bc56e6fe Mon Sep 17 00:00:00 2001 From: jinguang Date: Tue, 16 May 2023 11:23:22 +0000 Subject: [PATCH] !1478 [fix] optimize sig management description * Description:[fix] optimize sig management description --- sig/README.md | 281 +++++++++-------------------------------------- sig/README_EN.md | 127 +++++++++++---------- 2 files changed, 117 insertions(+), 291 deletions(-) diff --git a/sig/README.md b/sig/README.md index 8fdac10..b7aec74 100644 --- a/sig/README.md +++ b/sig/README.md @@ -1,236 +1,63 @@ -# SIG管理章程 +OpenHarmony社区SIG管理制度 +==================== 简体中文 | [English](./README_EN.md) -# OpenHarmony社区SIG管理制度 -本文档主要介绍OpenHarmony社区SIG（Special Interest Group）的管理制度，包括申请新SIG和SIG的运营、变更及终止。 +本文档介绍OpenHarmony社区的Special Interest Group（SIG）管理制度，包括新SIG的申请、运营、变更和终止。 -## 一、申请新SIG +一、申请新SIG +-------- -### 1.申请准备 +### 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。 +* 开发者需要仔细阅读[SIG管理制度](../zh/sig_governance.md)，了解OpenHarmony社区SIG的运作规则，并准备SIG章程和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](mailto: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://docs.qingque.cn/s/home/eZQB8yRFQfEFeAxk_6JKZEE0q?identityId=1tbICPd8j3s)，按时接入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发起人需要按照[SIG章程模板](../meeting-notes/docs/openharmony_sig_template.pptx)创建SIG提案初稿，完成[申请流程](../zh/sig_governance.md)。 + +### 3.PMC审批提案 + +* SIG发起人可以在PMC例行会议上提交新建SIG议题，并介绍待新建的SIG。PMC会审批SIG的成立，批准相关SIG仓库和沟通渠道的建立。 +* 评审会议形成会议纪要，并附上PMC的审批意见。 + +### 4.创建SIG组 + +* SIG发起人在收到PMC审批反馈并确认SIG提案通过后，执行以下操作： +* 按照[创建操作流程](../zh/sig_governance.md)创建SIG组。 + +二、SIG运营 +---------- ### （一）SIG仓库及沟通渠道 -1. SIG使用社区统一基础设施开展工作和交流，包括Gitee仓库和邮件列表。 -2. 新SIG负责人在[OpenHarmony/community仓库](https://gitee.com/openharmony/community)提交Issue，申请为该SIG新建仓库及邮件列表。 -3. Issue中应注明仓库路径、邮件列表名称以及新SIG的Leader和Committer，并附[前述PMC评审意见](#3pmc评审提案)，通过在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年度工作进展； -- 协助存在关联关系的周边SIG，联合完成临时性工作； -- 基于社区定期的SIG成果评估，表现优秀的SIG将被邀请参加社区版本发布会议。 - -#### 3.技术决策 -- SIG内的决策遵循OpenHarmony社区的治理模式。 -- SIG内采用“懒惰共识”（沉默即同意）的方式进行决策： -- 如存在争议时，由包括Leader在内的全体Committer进行投票表决，以多数票通过的形式达成共识； -- 无法在SIG内达成共识时，可上升至PMC决策。 - -## 三、SIG变更 - -### （一）增删项目或仓库 -1. SIG负责人在PMC例行会议中申报议题，接受PMC问询。 -2. PMC批准增删项目或仓库后，SIG负责人： -- 在`OpenHarmony/community`创建Issue请求SIG Architecture支持，完成新项目仓库的配置或删除仓库，Issue中附PMC评审意见； -- 相关操作完成、Issue关闭后，更新`sigs.json`文档（参考[上文](#4提交pr)），刷新`README.md`； -- 提交PR请求合并以上修改，PR中附PMC评审意见。 -3. Community仓的Committer合并PR，完成项目或仓库更新。 - -### （二）修改SIG名称、章程、成员等 - -#### 涉及SIG工作范围、成员变更等重大变更 -1. SIG负责人在PMC例行会议中申报议题，接受PMC问询。 -2. PMC批准变更后，SIG负责人： -- fork的`OpenHarmony/community/sig`的相关SIG文件夹内刷新`README.md`、`OWNERS.md`、等文档； -- 提交PR，请求合并以上修改，PR中附PMC评审意见。 -3. Community仓的Committer审核并合并PR，确认变更。 - -#### SIG内的非重大变更 -1. SIG负责人： -- fork的`OpenHarmony/community/sig`文件夹下找到相关SIG文件夹，完成修改； -- 刷新README.md等文档； -- 提交PR，请求合入以上修改。 -2. Community仓的Committer审核并合并PR，确认修改。 - -区分变更重大与否的标准可参考上文[SIG的运营部分](#二sig运营)。 - -## 四、SIG终止 - -### （一）以下情况将触发SIG终止申请： -1. SIG已达到预期目标，无需再投入； -2. SIG未达成预期目标，超过2个月不活跃； -3. SIG违反OpenHarmony社区PMC或SIG制度； -4. SIG Leader、Committer等成员流失，无法支撑SIG正常工作。 - -### （二）SIG QA定期检查各SIG状态，并定期在PMC会议中汇报各SIG活跃度： -1. 对于已达到预期目标的SIG，由SIG Leader通过邮件列表dev@openharmony.io提交SIG终止申请，PMC评估后进行终止操作。 -2. 对于未达到预期目标但不活跃的SIG，PMC委派PMC成员进入该SIG进行尽职调查，并组织SIG整改，整改时间2个月。SIG超过2个月依然不活跃时，由SIG Leader或QA-SIG Leader提交SIG终止申请，PMC评估后进行终止或合并操作。 - -### （三）终止流程： -1. 向dev@openharmony.io发送电子邮件，通知社区解散或合并SIG。 -2. SIG负责人在`OpenHarmony/Community`下创建一个PR，请求合并以下更改： -- 归档代码仓（[归档地址](https://gitee.com/openharmony-retired)） -- 删除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目录内： -1. sig_xxx.md/sig_xxx_cn.md：包括SIG组工作目标和范围、SIG管理的repository及描述、SIG组织会议、SIG成员。 - -2. 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。 - -3. 代码的管理 - - 代码在[sig-manifest仓](https://gitee.com/openharmony-sig/manifest)下统一管理。 - - - 需要各leader维护本组内对应仓的 .xml 文件。 - - - 多个单位参与，可向leader提出建仓需求，由leader向社区提建仓pr。 - -4. 文档的管理 - - 各sig组的公共文档（包括会议纪要、会议材料等）需放入[sig-content](https://gitee.com/openharmony-sig/sig-content) 仓对应组的文件夹内。 - - 与各sig组子任务密切相关的技术文档可放到任务对应的代码仓内。 - -5. 任务进度 - - - 任务进度以在对应任务仓下提issue形式更新。 - - 作为跟踪进度的issue需要打上特定的标签，标签暂定为 **sig_taskprogress**。 - -6. 开源协议的选择 - - 建议开发者使用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"] - }, - ] -} -``` + +1. SIG使用OpenHarmony社区的统一基础设施进行工作和交流，包括Gitee仓库和邮件列表。 +2. 有关仓库创建、更名、退出的流程，请参考[操作流程](../zh/sig_governance.md)。 +3. SIG邮件列表的负责人可以联系 **[xzmu@openatom.org](mailto:xzmu@openatom.org)** 创建邮件列表： + * 需详细说明邮件列表名称和管理员邮箱（一般为SIG负责人）。 + * 邮件列表创建成功后 + +4. SIG负责人应确保SIG仓库和沟通渠道的有效运作，并及时回应成员的问题和反馈。 + +### （二）SIG会议 + +1. SIG应定期召开会议，以促进成员之间的交流和合作。会议可以是线上或线下形式，根据成员的地理位置和可行性进行安排。 +2. SIG会议的召集人应提前通知成员会议的时间、地点（如果是线下会议）和议程。通知可以通过邮件列表、社区论坛或其他适当的沟通渠道进行。 +3. SIG会议的议程应包括SIG的进展报告、讨论重要议题和决策等内容。会议纪要应当记录会议的要点、讨论结果和决策事项，并及时分享给SIG成员。 + +### （三）SIG管理 + +1. SIG负责人应确保SIG的正常运行和管理，并与PMC保持沟通和协调。 +2. SIG负责人有权决定SIG的工作方向、任务分配和成员加入等事项。 +3. SIG负责人应定期向PMC和社区成员报告SIG的工作进展和成果。 +4. SIG负责人可以根据需要组织工作小组或任务组，协调成员的工作并推进SIG的目标。 +5. 如有需要，SIG负责人可以向PMC提出变更或终止SIG的申请，并提供充分的理由和解释。 + +### 三、SIG变更和终止 +------- +1. SIG的变更包括SIG负责人的更替、工作方向的调整、任务的重新分配等。SIG负责人应及时通知PMC和SIG成员，并经过协商和讨论确定变更事项。 +2. 如有需要终止SIG，SIG负责人应向PMC提交终止申请，并提供充分的理由和解释。PMC将根据情况评估和决定SIG的终止事宜。 diff --git a/sig/README_EN.md b/sig/README_EN.md index c7a5263..a7149bb 100644 --- a/sig/README_EN.md +++ b/sig/README_EN.md @@ -1,66 +1,65 @@ -# SIG Management Regulations +OpenHarmony Community SIG Governance +==================================== English | [简体中文](./README.md) -## Background -Under the guidance of the Project Management Committee (PMC), a special interest group (SIG) designs the architecture, develops open capabilities, and performs maintenance for innovative projects in a specific domain. -This repository stores information about all the SIGs in the OpenHarmony community. - -## Applying for Creating an SIG -1. Seek two or three developers in the community who have the same interest or objectives as you and elect a leader for this SIG. Create an SIG proposal based on the [SIG creation template](sig_template/sig_template.md), The proposal includes the following elements: - -Create background information for the SIG - -Create the business scope of the SIG - -Create business goals for the SIG -2. The SIG leader sends the SIG proposal via an email with the title [New-sig_Proposal-XXX] to dev@openharmony.io. -3. Wait for the PMC or the corresponding field SIG, Committer to approve the proposal, the proposer could filed agenda collection on [PMC](https://docs.qingque.cn/s/home/eZQB8yRFQfEFeAxk_6JKZEE0q?identityId=1tbICPd8j3s), PMC will periodic organization review meeting for the proposal. The proposer could go to the [Community](https://gitee.com/openharmony/community) repository to create a Pull Request to create a new SIG after passing the review and perfecting it in accordance with the review comments. --**Important**: If you need to apply for a new warehouse in the SIG, please report the issue of new parts to the [Architecture SIG](https://shimo.im/sheets/StzhuFkEk38enrnl/MODOC). - - -## Joining an SIG -1. Find an SIG you are interested in and participate in its technical discussions, maintenance, and capability development by various means, such as subscribing to mailing lists and attending meetings of the SIG. - -## Operating and Maintaining an SIG - -1. The SIG leader forks the **OpenHarmony/community** release, creates a folder and names it with the SIG name in the **sig** directory, creates an SIG profile in the created folder based on the [SIG template](sig_template/), and submits pull requests (PRs) for incorporating modifications of the SIG profile into the master code of OpenHarmony. - -2. SIG incubation projects are stored in the [OpenHarmony-SIG](https://gitee.com/openharmony-sig) organization. The code of incubation projects that meet graduation requirements can be incorporated into the master code of OpenHarmony. - -3. The SIG leader and committer operate and maintain the SIG. - -4. The SIG leader periodically reports the progresses of the SIG operations and incubation projects to the PMC which then offers suggestions. - -## Graduation of SIG Incubation Projects -1. If your SIG incubation project meets graduation requirements, you can apply for incorporating its code into the master code of OpenHarmony. -2. The SIG leader sends a graduation application for the incubation project to dev@openharmony.io. -3. After the PMC approves the graduation application, you can incorporate the code of the incubation project into the master code of OpenHarmony. - -### How SIG Data Is Stored and Managed -SIG data is stored in the **sig** directory of the **OpenHarmony/community** repository. The **sig_***xxx***.md**/**sig_***xxx***_cn.md** file is a template that contains the objectives and work scope of this SIG, repositories managed by the SIG and their descriptions, and SIG meetings and members. A backup of the maintainer/committer information of the SIG is stored in the **OWNER** file and can be automatically obtained by a tool. The names and directory structures of the repositories managed by each SIG are stored in the **sigs.json** file. -1. The **sigs.json** file in the **sig** directory of the **OpenHarmony/community** repository is used to manage all the SIGs visible to the PMC. -2. The PMC modifies and maintains SIGs. Maintainers submit PRs for modifying SIGs, and the PMC reviews the PRs and incorporates the modifications into the master code of OpenHarmony. -3. The **sig_***xxx***.md**/**sig_***xxx***_cn.md** file in the **sig** directory stores SIG data. In this file, the basic SIG information is empty and needs to be specified during SIG creation. -4. The **OWNER** file in the **sig** directory stores information about the maintainer of the SIG. - - -### sigs.json File -| Field | Description | -|:---|:---| -| sig_name | SIG name | -| projects| Gitee repository name | -| project-path | Archive path of the OpenHarmony project. Enter **NONE** if the code of the SIG does not need to be incorporated into the master code of OpenHarmony. | - -### sigs.json Sample -``` -"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"] - }, - ] -} -``` + +This document outlines the governance system for Special Interest Groups (SIGs) in the OpenHarmony community, including the application, operation, modification, and termination of SIGs. + +A. Applying for a New SIG +-------------------------- + +### 1. Preparation for Application + + * Developers should carefully read the [SIG Governance Document](../zh/sig_governance.md) to understand the operational rules of SIGs in the OpenHarmony community. They should also prepare documents such as the SIG Charter and SIG Bylaws. + * SIG applicants need to ensure the uniqueness and feasibility of their technical direction: + * Each SIG in the OpenHarmony community has a different technical focus. If the proposed application falls within an existing technical area, it is recommended to participate in the relevant SIG instead. + * Developers can review the [existing SIG list](https://gitee.com/openharmony/community/tree/master/sig) in the OpenHarmony community and check the [historical DEV mailing list](https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/) to confirm that there are no ongoing or planned SIGs with the same technical focus. + * The technical project proposed for establishing a SIG should eventually translate into a new component of OpenHarmony. + * If developers have any doubts about the technical direction after reviewing the relevant information, they can consult the PMC via the mailing list [dev@openharmony.io](mailto:dev@openharmony.io). + +### 2. Submitting the Application + + * SIG initiators need to create an initial draft of the SIG proposal following the [SIG Charter Template](../meeting-notes/docs/openharmony_sig_template.pptx) and complete the [application process](../zh/sig_governance.md). + +### 3. PMC Approval of the Proposal + + * SIG initiators can submit the new SIG proposal during a regular PMC meeting and present the details of the proposed SIG. The PMC will review and approve the establishment of the SIG, including the creation of relevant SIG repositories and communication channels. + * A meeting summary will be created, including the PMC's approval comments. + +### 4. Creating the SIG Group + + * After receiving the PMC's feedback and confirmation of the approved SIG proposal, the SIG initiator should proceed as follows: + * Follow the [creation process](../zh/sig_governance.md) to create the SIG group. + +B. SIG Operation +----------------- + +### (A) SIG RepositAories and Communication Channels + +1. SIGs should utilize the unified infrastructure provided by the OpenHarmony community for work and communication, including Gitee repositories and mailing lists. +2. For the process of repository creation, renaming, or exiting, please refer to the [operational process](../zh/sig_governance.md). +3. The person responsible for the SIG mailing list can contact **[xzmu@openatom.org](mailto:xzmu@openatom.org)** to create the mailing list: + * Provide detailed information on the mailing list name and the administrator's email address (usually the SIG leader). + * Once the mailing list is successfully created: +4. The SIG leader should ensure the effective operation of SIG repositories and communication channels, promptly responding to members' questions and feedback. + + +### (B) SIG Meetings + +1. SIGs should hold regular meetings to facilitate communication and collaboration among members. Meetings can be conducted online or offline, depending on the geographical locations and feasibility for participants. +2. The meeting convener should notify the members in advance of the meeting time, location (if offline), and agenda. Notifications can be sent through mailing lists, community forums, or other appropriate communication channels. +3. The meeting agenda should include progress reports, discussions on important topics, decision-making, and other relevant discussions. Meeting minutes should capture the key points, discussion outcomes, and decisions made during the meeting, and should be shared with SIG members in a timely manner. + +### (C) SIG Management + +1. The SIG leader is responsible for ensuring the normal operation and management of the SIG, as well as maintaining communication and coordination with the PMC. +2. The SIG leader has the authority to determine the work direction, task assignments, and membership of the SIG. +3. The SIG leader should regularly report the progress and achievements of the SIG to the PMC and the community members. +4. The SIG leader can organize working groups or task groups as needed to coordinate the work of the members and advance the goals of the SIG. +5. If necessary, the SIG leader can submit requests for changes or termination of the SIG to the PMC, providing sufficient reasons and explanations. + +C. SIG Modification and Termination +------------------------------------ + +1. SIG modification includes changes in SIG leadership, adjustments in the work direction, and reassignment of tasks. The SIG leader should promptly inform the PMC and SIG members, and the changes should be determined through consultation and discussion. +2. If there is a need to terminate a SIG, the SIG leader should submit a termination request to the PMC, along with sufficient reasons and explanations. The PMC will assess and decide on the termination of the SIG based on the circumstances. -- GitLab