diff --git a/Governance.md b/Governance.md
index 54884ed08f99a50c5f24b48f3fc6eab636d3494a..11df474511c10ede9c94bb179251cdb4cbafd580 100644
--- a/Governance.md
+++ b/Governance.md
@@ -51,9 +51,31 @@ SIG组内的交流必须是公开的，以确保其他SIG组的社区成员可
-### 委员会
+#### SIG、项目和repository
+
+> **SIG**：顾名思义，是一个团队，代表一群**“人”**
+>
+> **项目**：是为了完成某一特定目标而相互关联的任务，代表一组**“事”**
+
+
+
+SIG会针对一个或多个主题树立目标，从而成立项目去实现目标。目标的交付成果（包括代码和软件包）保存在repository内。所以项目和repository是息息相关的。综上SIG、项目和repository的关系是：
+
+- 一个SIG至少有一个项目
+
+- 一个项目对应一个或多个repository（交付成果为便于管理，会保存在多个相关的repository内）。
+
+- 一个项目可以由SIG内的一部分人参与，也可以由SIG内的所有人参与。
------
+
+
+**由于项目的相关任务和成果均在repository上管理，所以在openEuler社区，项目等同于repository(ies)，它可以代表一个repository，也可以代表一组相关的repository**。
+
+
+
+
+
+### 委员会
SIG是在公开场合运作的自愿团体，任何人都可以加入。但因为某些领域需要谨慎处理（例如安全性），所以委员会不公开成员资格，而且并不总是公开运作。
diff --git a/README_cn.md b/README_cn.md
index 3a18f62e21b16f010b12629c5324e4345639d0d5..d083738971456375feedd62ec18f5bc8f09f4325 100644
--- a/README_cn.md
+++ b/README_cn.md
@@ -16,7 +16,7 @@
- [秘书处](/zh/secretariat)
- [安全委员会](/zh/security-committee)
- [技术委员会](/zh/technical-committee)
- - [项目组](https://openeuler.org/zh/sig.html)
+ - [SIG](https://openeuler.org/zh/sig.html)
- [社区活动](https://openeuler.org/zh/events.html)
- [开发者贡献指南](https://openeuler.org/zh/developer.html)
diff --git a/sig/sig-template/README.md b/sig/sig-template/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..cffef9fc520cd392000c3bc7873c5c6ae03ce5fa
--- /dev/null
+++ b/sig/sig-template/README.md
@@ -0,0 +1,53 @@
+***注意：本文档所有的斜体内容，请在完成时删除***
+
+# SIG名称
+
+*<请在此描述SIG的范围、工作职责和目标，可以直接用sig-template.md内描述的第一个章节>,*
+
+
+
+# 组织会议
+
+- 公开的会议时间：北京时间，每周X 下午，XX点~XX点
+
+*<请在此给出SIG会议的时间>*
+
+
+
+# 成员
+
+*<请在此给出团队成员的列表>*
+
+### Maintainer列表
+
+- name[@giteeID](giteeID链接)
+
+
+
+### Committer列表
+
+- name[@giteeID](giteeID链接)
+
+
+
+# 联系方式
+
+*<如果需要单独申请邮件列表，请在此补充邮箱名称：sig-yousigname@openeuler.org>*
+
+- [邮件列表](sig-yoursigname@openeuler.org)
+- [IRC公开会议]()
+
+
+
+
+
+# 项目清单
+
+*<项目名称和申请表格一致，具体地址可以在申请下来以后在刷新>*
+
+项目名称：
+
+repository地址：
+
+-
+-
\ No newline at end of file
diff --git a/sig/sig-template/sig-template_cn.md b/sig/sig-template/sig-template_cn.md
index ce2d53075721e8396a83f948c4bb522e30f4bfa3..d436d7c3180fffe310c254e7f2d172ef9b68f330 100644
--- a/sig/sig-template/sig-template_cn.md
+++ b/sig/sig-template/sig-template_cn.md
@@ -16,18 +16,17 @@
- 该SIG需要得到openEuler内哪些SIG的支持
- ### 交付件
- 该SIG负责的交付件是哪些以及哪种形式
-
- - 源码
+ ### 该SIG管理的repository及描述
+
+- 项目名称：
+ - 交付件形式：源码、tar包或兼而有之
+ - repository1名称：
+ - repository2名称：
+
- - tar包
- - 源码和tar包
-
- ### 该SIG管理的个repository及描述
### 跨领域和面向外部的流程
@@ -38,26 +37,3 @@
- 该SIG拥有的面向整个openEulerSIG的组织指导计划等
-## 基本信息
-
-### 项目介绍
- https:/gitee.com/openeuler/community/sig/sig-xxxx/
-
-***提示***：在SIG创建成功后，https:/gitee.com/openeuler/community/sig/sig-xxxx/管理将由Maintainer负责，项目组可以丰富自己的项目介绍，包括但不限于如下内容。
-```
-### Maintainers
-- 姓名 (Gitee ID)
-
-### Committers
-- 姓名 (Gitee ID)
-
-### Mailing list
-
-### IRC Channel
-
-### 会议信息
-
-### 对外联络人
-- 姓名 (Gitee ID)
-```
-
diff --git a/zh/contributors/rule-introduce-package.md b/zh/contributors/rule-introduce-package.md
new file mode 100644
index 0000000000000000000000000000000000000000..02fd681e253b5b095fb67cb31c62b3b811b2499c
--- /dev/null
+++ b/zh/contributors/rule-introduce-package.md
@@ -0,0 +1,571 @@
+# openEuler 软件引入策略原则
+
+
+
+## 版本
+
+
+
+- 2020-01-11 Initial Draft by Xinwei Hu
+
+- 2020-01-21 Integrate input from Liang Chengye, Wang Lingzhuo, Guodong Xu and Yang Li
+
+
+
+ **目录**
+
+- [关于本文档](#id1)
+ - [目标](#id1-1)
+ - [范围](#id1-2)
+
+ - [本文的改进和修订说明](#id1-3)
+- [软件选型及引入](#id2)
+ - [什么是软件选型](#id2-1)
+ - [软件选型规则的适用范围](#id2-2)
+ - [软件包进入选型的两个基本前置条件](#id2-3)
+ - [openEuler软件包引入原则](#id2-4)
+ - [黑名单机制](#id2-5)
+- [软件包的元数据](#id3)
+ - [元数据的存储](#id3-1)
+ - [元数据库中的 Identification](#id3-2)
+ - [元数据库中的 主页地址 ](#id3-3)
+ - [元数据库中的 REPO地址](#id3-4)
+ - [元数据库中的 LANG](#id3-5)
+ - [元数据库中的 TAG](#id3-6)
+ - [元数据库中的 LISENCE](#id3-7)
+ - [元数据库中的 项目关系](#id3-8)
+ - [选型过程 request](#id3-9)
+ - [附带软件的选型入库](#id3-10)
+ - [软件是否存在于公开的语言库 **TODO**](#id3-11)
+ - [项目关系列表](#id3-12)
+
+
+
+
+
+关于本文档
+目标
+ openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler
+
+
+
+- 尽可能集成多的软件组件
+
+- 鼓励所有人使用openEuler，并可以在openEuler上开发软件
+
+- 使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质
+
+
+
+openEuler遵从 [Open Source Definition](https://opensource.org/docs/osd) ，满足这一定义的软件，被openEuler社区认同为开源软件。
+
+
+
+提供适度，高质量的开源软件是openEuler主要目标之一。openEuler努力为其所提供的开源软件在生命周期内提供高质量的支持服务。开源软件自由众多，质量不一。本着提供高质量开源软件的宗旨，特别拟定本规则指南。本规则的中**必须**，**必须不能**，**应该**，**应该不能**的含义参考rfc2119。
+
+
+
+范围
+ 本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。
+
+
+
+本文的改进和修订说明
+
+- 本文档由openEuler技术委员会 （Technical Committee）主导起草和维护。本文档的最新版本总可以在 XXXXXX [URL] 上找到。
+
+- **所有对本文档的修改意见可以通过邮件列表 XXXXX 反馈和讨论。 任何对于本文中涉及的规则的增加，修改，删除都**必须**被追踪，[请进入该追踪系统](https://gitee.com/openeuler/community/issues) 。**
+- 最终规则的经过充分的讨论后，由技术委员会定稿。
+
+
+
+
+
+软件选型、选型规则及引入原则
+什么是软件选型
+
+ 一个软件的选型指的是一个软件(项目)从用户库被申请引入到官方库，依照本文件描述的规则讨论，进而满足规则要求，最终引入官方库的过程。
+
+整个引入的过程都**必须**可被追踪。目前 [https://gitee.com/src-openeuler/openEuler-repos/issues](https://gitee.com/src-openeuler/openEuler-repos/issues) 是这个过程的追踪系统。
+
+
+
+软件选型规则的适用范围
+
+ 选型规则约束一个软件(项目)是否可以被引入到src-openeuler.yaml文件中，并在src-openeuler中作为一个目录维护。
+
+**注意**：升级一个官方库中已存在的软件包不是软件选型，所以不在本规则的覆盖范围内。
+
+
+
+软件包进入选型的两个基本前置条件
+
+凡是需要引入到openEuler的开源软件(项目)，**必须**有唯一的ID。这个ID是openEuler中管理开源项目的元数据库中的唯一标识。
+
+- 第一步：在元数据库中创建一个item。
+
+- 第二步：以元数据库的ID做为标识来讨论的软件(项目)。
+
+
+
+openEuler软件包引入原则
+
+为实现对软件生命周期的维护和管理，基于证据的可信贯穿于选型的整个过程。在一个软件包被引入的每一步都需要有记录，这些记录被作为可信过程的存证。
+
+* 一次**必须**只能引入一个软件。
+
+* 软件**应该**有明确的引入理由。
+
+* 软件**应该**是开源软件，开源软件的定义参考[https://opensource.org/osd.html](https://opensource.org/osd.html) 。如果非开源软件，经由technical committ讨论后决定。
+
+* 软件**应该**是源码包，原则上二进制**不应该**被引入。如果需要引入二进制，经由Technical Committ讨论后决定。
+
+* 原则上，该软件**应该**在openEuler上可以被正确构建。当软件有尚未被引入的依赖关系，或者软件的运行或者构建依赖一个绝不可能引入openEuler的组件，此等例外，经由Technical Committ讨论后决定。
+
+* 原则上，openEuler不引入**rootkit**或者其他类似存在可信问题的软件。
+
+* 存在于**黑名单**的软件**必须不能**引入。
+
+* 每一个软件的引入决定，都作为案例，作为后续类似软件引入决策的参考。Technical Committ对软件引入原则的一致性负责。
+
+
+
+黑名单机制
+
+Technical Committ讨论后，可以将被拒绝引入的软件被记录到一个软件黑名单，作为证据减少重复劳动。
+
+https://gitee.com/src-openeuler/openEuler-repos/software-blacklist.md
+
+
+
+
+
+元数据
+元数据的存储
+
+鉴于目前openEuler采用RPM作为包管理系统，同时考虑到对元数据的需求，本规则定义的元数据需要考虑兼容RPM SPEC的前提下作为单独的一份文件存储于RPM SRC包中。所有的软件包都应提供其元数据信息，该信息需符合以下openEuler软件包元数据定义的模板要求。
+
+**注意**：该独立的文件名字是meta.json，并采用json的数据格式。
+
+
+
+元数据库中的 Identification
+
+#### 目的
+
+
+
+ 唯一识别该软件
+
+
+
+#### 强制性
+
+
+
+* **必须**
+
+
+
+#### 作用
+
+
+
+引入的软件**必须**有唯一的ID。ID可以用来描述不同软件包之间的关系，所以ID的唯一性很重要。
+
+
+
+#### 格式
+
+
+
+##### RPM SPEC
+
+
+
+```SPEC
+
+Name: openssl
+
+```
+
+
+
+RPM 包的名字，在整个REPO具有唯一性，可以作为ID。
+
+
+
+##### Json ORG style
+
+
+
+org id, 代表该软件包项目的组织ID，类似namespace的作用。
+
+art id, 代表该项目的ID
+
+
+
+json的表达格式实例
+
+```json
+
+"id": {
+
+ "org": "org.openssl",
+
+ "art": "openssl"
+
+}
+
+```
+
+
+
+推荐，如果同时提供RPM SPEC的方式和Json ORG style两种，**应该**考虑名字的一致性。
+
+
+
+元数据库中的 主页地址
+
+#### 目的
+
+
+
+一个开源项目的真正的实质。它和ID在一起作为元数据库中跟实际项目的binding。
+
+不同的ID的项目**应该不能**一样。一个项目只能由一个官方主页。
+
+
+
+#### 强制性
+
+
+
+* **必须**
+
+
+
+#### 格式
+
+
+
+##### RPM SPEC
+
+
+
+```SPEC
+
+URL: https://www.openssl.org/
+
+```
+
+
+
+##### JSON style
+
+
+
+ 软件包的 主页地址，任何一个开源软件都需要有一个主页，如果没有正式的官方主页，那可以认为软件的发布页为主页，比如github的项目主页。
+
+
+
+json的表达格式的实例
+
+```json
+
+"official": "https://www.openssl.org/"
+
+```
+
+
+
+元数据库中的 REPO地址
+
+#### 目的
+
+
+
+保存该开源项目的repo地址。可以有多个。
+
+
+
+#### 强制性
+
+
+
+* **可选**
+
+
+
+#### 格式
+
+
+
+##### JSON style
+
+
+
+```JSON style
+
+"repo": [
+
+ "git://git.openssl.org/openssl.git",
+
+ "https://github.com/openssl/openssl.git"
+
+]
+
+```
+
+
+
+元数据库中的 LANG
+
+#### 目的
+
+
+
+说明该项目使用的主要编程语言。
+
+
+
+#### 强制性
+
+
+
+* **可选**
+
+
+
+#### 格式
+
+
+
+##### JSON style
+
+
+
+```JSON style
+
+"lang": [
+
+ "c"
+
+]
+
+```
+
+
+
+元数据库中的 TAG
+
+#### 目的
+
+
+
+说明该项目主要的应用领域的其它属性。
+
+
+
+#### 强制性
+
+
+
+* **可选**
+
+
+
+#### 格式
+
+
+
+##### JSON style
+
+
+```JSON style
+
+"tag": [
+
+ "protocol",
+
+ "tls"
+
+]
+
+```
+
+
+
+元数据库中的 LISENCE
+
+#### 目的
+
+
+
+说明该项目用来描述该项目使用的LISENCE，LISENCE需要使用SPDX定义的ID。
+
+
+
+#### 强制性
+
+
+
+* **必须**
+
+
+
+#### 格式
+
+
+
+##### JSON style
+
+
+
+为兼容SPDX，使用来自SPDX标准的命名。
+
+```JSON style
+
+"lisence": [
+
+ "SPDX-License-Identifier: OpenSSL"
+
+]
+
+```
+
+
+
+元数据库中的 项目关系
+
+#### 目的
+
+
+
+说明该项目用来描述该项目之间关系。这个关系可用分析项目直接的关系，其中requires的关系可以直接推导出运行时的依赖关系。
+
+
+
+#### 强制性
+
+
+
+* **可选**
+
+
+
+#### 格式
+
+
+
+##### RPM SPEC
+
+
+
+```SPEC
+
+Requires: coreutils perl ca-certificates crypto-policies
+
+```
+
+
+
+##### JSON style
+
+
+
+为兼容SPDX，使用来自SPDX标准的命名。
+
+```JSON style
+
+"related": {
+
+ "HAS_PREREQUISITE": ["org.gnu.coreutils", "org.perl.perl", "ca-certificates", "crypto-policies"]
+
+}
+
+```
+
+
+
+##### 软件(项目)关系的定义列表见附件
+
+
+
+选型过程 request
+
+每次选型如果的请求都应该被记录，都应该可追溯。
+
+
+
+```text
+
+https://gitee.com/organizations/src-openeuler/issues
+
+```
+
+
+
+#### requester
+
+
+
+提出该次选型入库申请的申请人。该申请人**应该**是被申请包的作者。
+
+
+
+#### reason
+
+
+
+申请的理由，描述这个软件(项目)为什么应该存在于官方的repo中。
+
+
+
+#### result
+
+
+
+描述这次选型入库的申请是否通过。
+
+
+
+##### 取值
+
+
+
+* accepted **应该**有reason。
+
+* rejected **应该**有reason。
+
+
+
+附带软件的选型入库
+
+引入一个软件有可能附带引入其它软件(项目)，根据一次引入一个软件的原则，分别为每个软件提交请求，并且附带软件的引入原因需要体现被附带引入这个情况。
+
+
+
+软件是否存在于公开的语言库 TODO
+
+ 比如 Marven，PIP，Python，NPM，Ruby等等，
+
+ 如果有**应该**提供在所在语言库的链接。
+
+
+
+项目关系列表
+
+为兼容SPDX，使用来自SPDX标准的命名。
+
+
+
+| relation | description |
+
+| -------- | ------------|
+
+| HAS_PREREQUISITE | 该软件需要其它的软件支持其运行，所有的被依赖软件都**应该**被列举。 相当于 RPM SPEC中 Requires |
+
+| PREREQUISITE_FOR | 该软件支撑了其它软件的运行，不能被完全列举。 |
+
+| HEEDS_BUILD_TOOL | 该软件构建时需要那些软件的支持。相当于 RPM SPEC 中 BuildRequires |
\ No newline at end of file
diff --git a/zh/technical-committee/governance/README.md b/zh/technical-committee/governance/README.md
index 703527351ce28a82a8c641b6f176bcaf9051fbbb..0794dc557f0b0c7caa4d6b45ca35cd895e720497 100644
--- a/zh/technical-committee/governance/README.md
+++ b/zh/technical-committee/governance/README.md
@@ -1,17 +1,31 @@
# SIG 管理指南
- 所有openEuler社区的SIG都必须有一个章程（Charter）来明确SIG的范围和治理规则。
+ 目录
+
+- [申请新SIG流程](#id1)
+- [SIG变更批准流程](#id2)
+ - [增删新项目或repository申请流程](#id2-1)
+ - [修改SIG章程申请流程](#id2-2)
+ - [变更团队成员申请流程](#id2-3)
+
+
+
+申请新SIG流程
+
+说明：
+
+所有openEuler社区的SIG都必须有一个章程（Charter）来明确SIG的范围和治理规则。
+ 范围必须明确定义SIG负责指导和维护的领域
+ 治理规则必须说明SIG中的职责，以及拥有这些职责的角色和工作开展方式
-## 申请新SIG的流程
+具体的申请流程如下：
**1、使用SIG模板创建自己的新SIG**
-将 gitee.com/openeuler/community Fork到你的Gitee下。
+将 gitee.com/openeuler/community Fork到你的Gitee下。并在sig目录下创建你的sig文件夹，以及把SIG申请模板拷贝到该文件夹下。
```
@@ -25,10 +39,9 @@ cd sig-YOURSIGNAME
```
-
**2、完成新SIG章程的填写**
-为便于更好的理解章程模板里的内容，建议先阅读[建议书和要求](./SIG-governance-requirements.md)，完成新SIG的申请填写。
+为便于更好的理解和填写[SIG申请模板](/../../sig/sig-template_cn.md)里的内容，建议先阅读[建议书和要求](./SIG-governance-requirements.md)，完成新SIG的申请填写。
```
mv sig-template_cn.md sig-YOURSIGNAME_cn.md
@@ -41,7 +54,7 @@ vi sig-YOURSIGNAME.md
```
-**3、完成新项目成员的配置**
+**3、完成新SIG成员的配置**
请在OWNERS文件中完成对SIG成员的配置
@@ -52,7 +65,7 @@ vi OWNERS
**4、完成新SIG的Repository的配置**
-请参考[openEuler的Repository说明](/zh/Gitee-Management/Gitee-management-guide.md)，完成SIG和项目所拥有的Repository的配置。
+请参考[openEuler的Repository说明](/zh/Gitee-Management/Gitee-management-guide.md)，完成SIG所拥有的Repository的配置。
- 如果您的项目在openEuler社区只维护软件包，请点击[src-openeuler.yaml](/repository/src-openeuler.yaml)，在其中按照格式把你的项目添加进来。
@@ -81,36 +94,227 @@ vi ../sigs.yaml
- src-openeuler/bbb
```
-**6、提交PR**
+**6、完成SIG的README初稿信息**
+
+一个sig的README是这个团队给贡献者们了解本团队的第一手资料。所以每一个sig团队都应该提供README里的相关信息。请按照README模板完成对sig团队的介绍
+
+```
+vi README.md
+```
+
+**7、提交PR**
将以上修改提交到Gitee上，并在Gitee上创建一个Pull Request。
-**7、向TC发送邮件申请**
+**8、向TC发送邮件申请**
给技术委员会发邮件（邮箱），并在正文中包含主题“[*新SIG提案]*”和PR的链接
-**8、TC评审并反馈意见**
+**9、TC评审并反馈意见**
+
+技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改
+
+**10.TC评审通过并合入**
+
+技术委员会将通过合并Pull Request的方式来批准您的申请
+
+
+
+
+
+SIG变更申请流程
+
+如果您要修改SIG章程（charter.md）、团队成员(OWNERS)、增删Repository(Repository)等，您需要提交SIG变更批准流程。
+
+增删新项目或repository申请流程
+
+**1、完成新项目的Repository的配置或删除相关配置**
+
+请参考[openEuler的Repository说明](/zh/Gitee-Management/Gitee-management-guide.md)，完成SIG所拥有的Repository的配置。
+
+- 如果您的项目在openEuler社区只维护软件包，请点击[src-openeuler.yaml](/repository/src-openeuler.yaml)，在其中按照格式对你的项目的repository进行添加/删除。
+
+```
+vi ../../repository/src-openeuler.yaml
+
+```
+
+- 如果不是以上的情况，请单击[openeuler.yaml](/repository/openeuler.yaml)，在其中按照格式对你的项目的repository进行添加/删除。。
+
+```
+vi ../../repository/openeuler.yaml
+
+```
+
+**2、在sig文件夹的sig.yaml内添加新项目的repository信息或删除相关信息**
+
+根据以上的信息，打开sig文件夹下[sigs.yaml](/sig/sigs.yaml)文件，在`name`字段下面找到项目所属的sig，可以在该sig的`repositories`的末尾添加项目的repository，或者找到待删除的repository进行删除。
+
+```
+vi ../sigs.yaml
+
+- name: sig-YOURSIGNAME
+ repositories:
+ - openeuler/aaa
+ - src-openeuler/bbb
+```
+
+**3、刷新README**
-8.技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改
+根据新增的项目和其repository，请同步刷新README内的“项目清单”下内容，便于大家查找
-**9.TC评审通过并合入**
+```
+vi README.md
+```
+
+**4、提交PR**
+
+将以上修改提交到Gitee上，并在Gitee上创建一个Pull Request。
+
+**5、向TC发送邮件申请**
+
+给技术委员会发邮件（邮箱），并在正文中包含主题“[*增删repository提案]*”和PR的链接
+
+**6、TC评审并反馈意见**
+
+技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改
+
+**7.TC评审通过并合入**
技术委员会将通过合并Pull Request的方式来批准您的申请
-## SIG变更批准流程
+修改SIG章程申请流程
+
+#### 重大变更申请流程
+
+待修改的sig章程涉及到**重大的变更**，或可能影响到其他sig，需要提交给技术委员会审核，请采用以下流程：
+
+**1、修改SIG章程**
+
+请在`/community/sig`文件夹下找到您的sig文件夹，完成sig文件夹的修改
+
+```
+vi sig-YOURSIGNAME_cn.md
+
+vi sig-YOURSIGNAME.md
+
+```
+
+**2、刷新README**
+
+请视需要，根据修改的章程同步刷新README内的“项目清单”下内容，便于大家了解
+
+```
+vi README.md
+```
+
+**3、提交PR**
+
+将以上修改提交到Gitee上，并在Gitee上创建一个Pull Request。
+
+**4、向TC发送邮件申请**
+
+给技术委员会发邮件（邮箱），并在正文中包含主题“[*修改SIG章程提案]*”和PR的链接
+
+**5、TC评审并反馈意见**
+
+技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改
+
+**6.TC评审通过并合入**
+
+技术委员会将通过合并Pull Request的方式来批准您的申请。并会通知收影响的其他SIG。
-如果您要修改SIG章程（charter.md）、团队成员(OWNERS)、增删Repository(Repository)。
-**1、对于影响范围小的变更**，比如只影响本SIG范围内的问题或领域（比如变更团队成员），PR申请填写完成以后，SIG的Mainatiner可以自行审批协助完成变更
-**2、对于以上的重大变更或可能影响其他SIG组的任何变更**（例如项目范围变更、增删Repository）
+**对于重大变更的操作说明**，为了加快重大变更的申请审批速度，可以采取以下方式：
+ 从SIG组中确定推动变更的负责人，最常见的就是SIG的Mainatiner作为负责人
+ 变更所有者组织SIG组成员一起制定变更内容，并与技术委员会讨论（为便于信息同步，可以在与指导委员会的沟通中键入SIG组的邮件列表）
-+ 获取到技术委员会的批准意见后，提交PR，并将该申请发送给[技术委员会邮件列表](tc@openeuler.org)，发送主题请标注成“【*SIG章程更新：*YOUR SIG/RPROJECT】”
-+ 对于较大的变更，确认变更范围后请通知openEuler社区内受到影响的其他SIG组，并将邮件发送到tc@openeuler.org，或者在社区门户上宣布。
-如果这一过程中有任何疑问，请联系技术委员会：
+
+
+
+
+#### 内部变更申请流程
+
+**只影响本SIG范围内的变更**，只需要SIG内的Maintainer达成一致，请走以下流程
+
+**1、修改SIG章程**
+
+请在`/community/sig`文件夹下找到您的sig文件夹，完成sig文件夹内SIG章程的修改
+
+```
+vi sig-YOURSIGNAME_cn.md
+
+vi sig-YOURSIGNAME.md
+
+```
+
+**2、刷新README**
+
+请视需要，根据修改的章程同步刷新README内的“项目清单”下内容，便于大家了解
+
+```
+vi README.md
+```
+
+**3、提交PR**
+
+将以上修改提交到Gitee上，并在Gitee上创建一个Pull Request。
+
+**4、在SIG内部发送邮件申请**
+
+给您所对应的sig团队的邮箱列表发邮件申请，可以在正文中包含主题“[*修改SIG章程提案]*”和PR的链接。如果之前在SIG团队内对此变更已经有讨论，可以省略该步骤
+
+**5、SIG内部评审并给出意见**
+
+如果您的SIG内部已经有评审意见，可以省略该步骤。
+
+**6.TC评审通过并合入**
+
+SIG的Maintainer合并Pull Request来批准申请。
+
+
+
+变更团队成员申请流程
+
+团队成员的刷新由SIG内部自己维护
+
+**1.完成新SIG成员的配置**
+
+请在`/community/sig`文件夹下找到您的sig文件夹，完成sig文件夹内SIG章程的修改，在OWNERS文件中完成对SIG成员的配置
+
+```
+vi OWNERS
+
+```
+
+**2、刷新README**
+
+请视需要，根据修改的章程同步刷新README内的“项目清单”下内容，便于大家了解
+
+```
+vi README.md
+```
+
+**3、提交PR**
+
+将以上修改提交到Gitee上，并在Gitee上创建一个Pull Request。
+
+**4、在SIG内部发送邮件申请**
+
+给您所对应的sig团队的邮箱列表发邮件申请，可以在正文中包含主题“[*修改SIG章程提案]*”和PR的链接。如果之前在SIG团队内对此变更已经有讨论，可以省略该步骤
+
+**5、SIG内部评审并给出意见**
+
+如果您的SIG内部已经有评审意见，可以省略该步骤。
+
+**6.TC评审通过并合入**
+
+SIG的Maintainer合并Pull Request来批准申请。
+
+
+