diff --git a/sig/README.md b/sig/README.md
index 760c2163468cb72492e587c787aeb131fd4be317..2d98fa439d1669846bb543bce4abc4cbfe4719c5 100644
--- a/sig/README.md
+++ b/sig/README.md
@@ -1,43 +1,185 @@
 # SIG管理章程
 简体中文 | [English](./README-EN.md)
 
-## 背景
- 1. SIG（Special Interest Group）是指特别兴趣小组，SIG在PMC项目管理委员会指导下，负责OpenHarmony社区特定子领域及创新项目的架构设计、开源开发及项目维护等工作。
- 2. 为了便于OpenHarmony开源社区工作开展和交流，默认将其划分为23个初始的SIG小组：[Maps_Sigs_Subsystem](./sigs_subsystem_list.md)。
- 3. 本目录用于存放OpenHarmony社区所有 “特别兴趣小组”（Special Interest Group，以下简称 SIG）的运作信息。
-
-## SIG职责&运作方式
- 1. 领域的技术演进方向由SIG组承担，负责领域技术竞争力分析和关键技术识别及决策。
- 2. 负责领域内功能分解分配，模块间接口定义与维护管理。
- 3. 社区的工作实体是SIG组，从基础设施到OS部件，从测试系统到版本发布都是由不同SIG的来承担。
- 4. 一个良好的社区组织形式是持续运作的关键，仪式感很重要，SIG组需要通过周期例会来保持其有效的运作，并定期向PMC委员会汇报进展。
-
-## 申请新建SIG
- 1. 开发者在社区中寻找2-3个以上有共同兴趣及目标的人，确定SIG Leader。参考[新建SIG Charter](sig-template/sig_template_cn.md)模板，创建SIG Charter提案，提案包括如下要素：
-     - 创建SIG的背景信息
-     - 创建SIG的业务范围
-     - 创建SIG的业务目标
- 2. **那些情形适合申请创建SIG**:
-     - 发起的申请属于OpenHarmony社区中的已有的技术方向, 建议直接参与到已创建的SIG组中进行共建；
-     - 发起孵化的技术项目, 能代表某一个领域的技术方向, 并最终能转化为OpenHarmony的新增部件；
- 3. SIG Leader以[SIG-Charter-Proposal-XXX]为邮件标题，需先订阅[dev@openharmony.io](https://lists.openatom.io/postorius/lists/dev.openharmony.io/)，将申请材料以附件方式向dev@openharmony.io发送邮件，提交新建SIG申请。
- 4. PMC或对应领域SIG、Committer邮件回复同意后，然后向[PMC](https://etherpad.openharmony.cn/p/pmc)申报议题，PMC会根据收到的议题统一安排SIG申请评审，PMC根据评审通过后，申请者按照评审意见完善后，向[Community](https://gitee.com/openharmony/community)仓创建新的SIG的Pull Request申请新建SIG。
-     - **重要**：SIG中如需新建仓申请的，请向[架构SIG](https://shimo.im/sheets/StzhuFkEk38enrnl/MODOC)中申报新增部件的议题。
-
-## 加入已有SIG
-1. 开发者可通过SIG列表查看感兴趣的SIG，通过订阅邮件列表、参与SIG会议等形式，参与对应SIG项目的技术讨论、社区维护及开源开发。
-
-## 运营维护SIG
-1. SIG Leader Fork OpenHarmony/community分支，在SIG文件夹下，以新SIG名称新建文件夹，并参考[SIG模板](sig-template/)，创建对应的SIG配置文件，提交PR合入申请。
-2. SIG孵化子项目，统一存放在[OpenHarmony SIG组织](https://gitee.com/openharmony-sig)，待孵化成熟后，可合入OpenHarmony组织代码主库。
-3. SIG Leader及Committer负责对应SIG的运营及维护，会议纪要和资料统一参考sig-template目录下的[meetings](https://gitee.com/openharmony-sig/sig-content)和[docs](https://gitee.com/openharmony-sig/sig-content)模版进行归档。
-4. SIG Leader定期在PMC项目管理委员会汇报SIG孵化项目及SIG运营进展，PMC基于SIG运作情况给出指导建议。
-
-## SIG孵化项目毕业
- 1. SIG孵化项目成熟并满足项目毕业要求后，可申请合入OpenHarmony组织代码主库。
- 2. SIG Leader通过向dev@openharmony.io发送邮件，提交孵化项目毕业申请。
- 3. PMC项目管理委员会通过项目毕业申请后，社区接纳孵化项目合入OpenHarmony主干。
- 4. 孵化项目毕业评审请按照[要求自检](./sig-QA/guidance_for_incubation_project_graduation_cn.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年度工作进展；
+- 协助存在关联关系的周边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目录内：
diff --git a/sig/sig-template/sig_template_cn.md b/sig/sig-template/sig_template_cn.md
index cc543d51049ad4368f69ff877b3e406421820d30..1d327078bb34ef1d3397d92acaa39207e0a2e3c6 100644
--- a/sig/sig-template/sig_template_cn.md
+++ b/sig/sig-template/sig_template_cn.md
@@ -11,6 +11,9 @@
 ### 工作范围
  _XXX_ 
 
+### 工作交付件及工作计划
+ _XXX_ 
+
 ## 代码仓
 - 代码仓地址：
   - repository1名称：https://gitee.com/openharmony/xxx