diff --git a/Governance.md b/Governance.md
new file mode 100644
index 0000000000000000000000000000000000000000..105a70f3d0b117f0af41b632401676e491c848c4
--- /dev/null
+++ b/Governance.md
@@ -0,0 +1,83 @@
+这里记录了openEuler社区当前的运作方式。
+
+
+
+# 原则
+openEuler社区遵循以下原则：
++ **开放**：openEuler是开源的和开放的
++ **尊重**：社区里的每一个人都必须遵守社区的行为准则
++ **透明**：社区内的工作和沟通都是以公开的形式进行的
++ **领先**：欢迎在社区开展技术孵化创新
+
+
+
+## 行为守则
+
+openEuler社区遵循[社区行为准则](code-of-conduct.md)
+
+
+
+
+## 社区成员
+
+请查看[社区成员](community-membership.md)
+
+
+
+
+##  社区团体
+
+请查看[社区团体](SIG&project-list.md)
+
+
+
+### SIG/项目
+
+------
+
+openEuler社区主要的组织构成是**SIG和项目**。
+
+每个SIG和项目的共同目的都是针对特定的一个或多个主题，推动交付成果输出，并争取让交付成果成为openEuler社区发行的一部分。SIG/项目的每个可识别的部分都属于该SIG/项目，包括存储库、目录、API、测试、问题、PR等。
+
+SIG/项目在任何给定时间内必须至少有一个，或多个Maintainer。Maintainer负责SIG/项目的运作，通过SIG/项目的治理实现特定的目标，并与团队成员一起与技术委员会、其他SIG/项目组、用户进行交流协同。
+
+每个SIG/项目都必须有一个章程，其中规定了SIG/项目的范围（主题、代码库、目录等）、职责、权限区域，如何选择/授予权限/领导权的成员和角色，如何制定决策和解决冲突，如何管理章程等信息，请参考[SIG/项目章程](/technical-committee/governance/SIG&project-governance.md)。在一些跨SIG/项目流程（如发布流程）和资产（如存储库）的广泛指导原则约束下，SIG/项目可以相对自定义的更改其操作方式。
+
+SIG/项目组内的交流必须是公开的，以确保其他SIG/项目组的社区成员可以找到讨论、会议、涉及和决策的记录，SIG/项目也需要定期向社区传递项目的工作概要。
+
+有关SIG/项目的治理的更多详细信息，请参考[SIG/项目治理](/technical-committee/governance/SIG&project-governance.md)、[SIG/项目治理要求](/techniacl-committee/governance/SIG&project-governance-requirements.md)。
+
+[openeuler.yaml]()中记录了每个SIG/项目。
+
+
+
+### 委员会
+
+-----
+
+SIG/项目是在公开场合运作的自愿团体，任何人都可以加入。但因为某些领域需要谨慎处理（例如安全性），所以委员会不公开成员资格，而且并不总是公开运作。
+
+ 技术委员会可以根据需要，在有限的时间内成立某一特定委员会。委员会的成员资格由技术委员会决定，但所有委员会成员必须是[社区成员](community-membership.md)。与项目一样，委员会也有章程，并定期向社区和技术委员会报告。
+
+
+
+## 跨项目沟通和协调
+
+一方面，跨SIG/项目协调的成本是昂贵的，虽然社区的大部分工作不需要协调，但仍然避免不了有跨越边界的工作（依赖等）。在这种情况下，期望多个SIG/项目之间互相协调并达成共识比较困难，组建联合工作组就显得很有意义了。
+
+另一方面，一些SIG确实会对所有SIG/项目产生影响，比如发布、测试、打包等。即使都不需要这些的软件，有时也可能需要进行变更或影响到其他SIG/项目。在这种情况下，所有SIG/项目都应遵守社区范围内的沟通流程。
+
+例如：具有影响力的提案需要在社区范围内公告，以便于其他SIG/项目组的成员有机会提供反馈和指导。不过本领域的项目拥有本领域的决策权。如果跨项目争议时间较长，则可以上升到技术委员会。
+
+
+
+## Repository指南
+
+openEuler Gitee下的所有的Repository都应该遵循[openEule的Repository指南](Gitee-management/README.md)中描述的过程。
+
+
+
+## CLA
+
+所有贡献者都必须签署openEuler CLA，请具体看[这里](CLA.md)。
+
diff --git a/README-ch.md b/README-ch.md
new file mode 100644
index 0000000000000000000000000000000000000000..13d377dca75072cf6fb990766fd1bda3a3c51cfe
--- /dev/null
+++ b/README-ch.md
@@ -0,0 +1,60 @@
+# openEuler社区
+
+欢迎来到openEuler社区！
+
+
+
+## 社区愿景
+
+openEuler的愿景是：**通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统openEuler，推动软硬件生态繁荣发展**。
+
+
+
+这里加入openEuler社区并为之贡献的起点。
+
+
+
+## 沟通交流
+
+
+openEuler社区有多种沟通渠道，请参考[社区交流](/communication)。
+
+
+
+## 社区治理
+
+
+openEuler有以下受官方支持的组织类型：
+
++ **委员会**：被授予承担一些敏感的主题的一组人。虽然社区鼓励尽可能开放，但是由于这组人所承担的主题的敏感性，允许进行私人的交流。比如安全委员会、打包委员会等
+
++ **SIG**：专注于**一个领域**的持久和开放的团队，该团队通过定期的任务和活动实现特定的交付目标。SIG具有公开透明的程序，要遵循openEuler的行为准则。任何人都可以参与并作出贡献。SIG的交付件要进入社区发行范围，可以向技术委员会提交申请，请参考相关[申请指导](/technical-committee/governance/README.md)。
+
++ **项目**：为实现**特定交付目标或成果**，由项目团队协作完成的任务（集）。项目组和SIG（特定兴趣小组）的区别在于，项目组专注于某一特定的交付成果。SIG（特定兴趣小组）专注于一个技术领域的技术贡献和创新孵化。比如*容器SIG*把*k8s*项目引入本小组的兴趣范围。为简化管理规则，项目管理和SIG治理共用一套机制。
+
+  **说明**：
+  
+- 项目可以属于一个SIG团队，成为SIG团队的子项目（共用SIG的治理机制），也可以单独治理
+  - 项目有两个阶段：孵化阶段和成熟阶段。成熟项目的软件包可以进入社区发行光盘。孵化项目可以申请软件包进入社区发行的`/extra`（不在光盘内的额外的软件包）目录或`/experimental`（探索、实验性质的软件包）目录
+
++ **工作组**：为了解决跨SIG/项目边界的问题而临时成立的小组。工作组不拥有任何代码或长期交付件。可以通过相关的SIG进行报告。比如社区安全编码工作组等。
+
+  有关这些组织的更多详细信息，可以参看[完整的管理文档](/technical-committee/governance.md)。SIG/项目可以由自己的贡献策略（在本SIG/项目组的repo中的”README“或”CONTRIBUTING“文件中描述）（例如sig-qa/CONTRIBUTING.md），以及自己的邮件列表、IRC频道等。
+
+如果您需要了解SIG/项目结构和组织的更多信息，请参阅[SIG/项目治理](/technical-committee/governance/SIG&project-goveranace.md)信息。
+
+
+
+## 贡献
+
+
+做出贡献的第一步是从[openEuler的SIG/项目列表中选择](SIG&project-list.md)。开始参加SIG/项目会议，加入IRC频道并订阅邮件列表。SIG/项目通常会由一系列`help-wanted`的ISSUE，这些ISSUE可以帮助新的贡献者参与进来。
+
+该[贡献指南](/guide/README.md)提供了如何让你的想法和bug修复被看到和接受的方法，其中包括详细的说明：
+
+1.如何提出问题
+
+2.如何找到可以工作的内容
+
+3.如果打开一个PR
+
diff --git a/SIG&project-list.md b/SIG&project-list.md
new file mode 100644
index 0000000000000000000000000000000000000000..fc122feb9ce88f8acac0903f9dfbd414ce73b1bf
--- /dev/null
+++ b/SIG&project-list.md
@@ -0,0 +1,25 @@
+# SIG、项目和委员会清单
+
+大多数社区活动都组织为SIG/项目。SIG/项目都遵循这些[准则](../Govern.md)。每个SIG/项目组的资料都在该SIG/项目的目录中。如果需要，可以[申请一个新SIG/项目](/technical-committee/governance/README.md)
+
+### 主要的SIG/项目清单
+
+| SIG/项目名称 | 类型 | Maintainer清单 | 联系方式 | SIG/项目会议时间 |
+| ------------ | ---- | -------------- | -------- | ---------------- |
+| qa           | SIG  |                |          |                  |
+| pm           | SIG  |                |          |                  |
+| release      | SIG  |                |          |                  |
+|              |      |                |          |                  |
+|              |      |                |          |                  |
+
+
+
+
+
+### 主要的委员会清单
+
+| 名称       | 标签 | 成员 | 联系方式 |
+| ---------- | ---- | ---- | -------- |
+| 安全委员会 |      |      |          |
+|            |      |      |          |
+
diff --git a/code-of-conduct.md b/code-of-conduct.md
new file mode 100644
index 0000000000000000000000000000000000000000..d5eb4b96086a8c6eabcb1a5a63b988d4c5f543f0
--- /dev/null
+++ b/code-of-conduct.md
@@ -0,0 +1,65 @@
+# openEuler社区行为守则
+
+openEuelr社区遵守开源社区[《贡献者公约》](https://contributor-covenant.org)V1.4中规定的行为守则，请参考[V1.4版本](https://www.contributor-covenant.org/zh-cn/version/1/4/code-of-conduct.html)
+
+
+
+如需举报侮辱、骚扰或其他不可接受的行为，您可以发送邮件至tc@openeuler.org，联系openEuler技术委员会处理。
+
+
+
+## 贡献者们的承诺
+
+为建设开放友好的环境，我们贡献者和维护者承诺：不论年龄、体型、身体健全与否、民族、性征、性别认同与表征、经验水平、教育程度、社会地位、国籍、相貌、种族、信仰、性取向，我们项目和社区的参与者皆免于骚扰。
+
+
+
+## 我们的准则
+
+有助于创造积极环境的行为包括但不限于：
+
+* 措辞友好且包容
+* 尊重不同的观点和经验
+* 耐心接受有益批评
+* 关注对社区最有利的事情
+* 与社区其他成员友善相处
+
+参与者不应采取的行为包括但不限于：
+
+* 发布与性有关的言论或图像、不受欢迎地献殷勤
+* 捣乱/煽动/造谣行为、侮辱/贬损的评论、人身及政治攻击
+* 公开或私下骚扰
+* 未经明确授权便发布他人的资料，如住址、电子邮箱等
+* 其他有理由认定为违反职业操守的不当行为
+
+
+
+## 我们的义务
+
+项目维护者有义务诠释何谓“妥当行为”，并妥善公正地纠正已发生的不当行为。
+
+项目维护者有权利和义务去删除、编辑、拒绝违背本行为标准的评论（comments）、提交（commits）、代码、wiki 编辑、问题（issues）等贡献；项目维护者可暂时或永久地封禁任何他们认为行为不当、威胁、冒犯、有害的参与者。
+
+
+
+## 适用范围
+
+本行为标准适用于本项目。当有人代表本项目或本社区时，本标准亦适用于此人所处的公共平台。
+
+代表本项目或本社区的情形包括但不限于：使用项目的官方电子邮件、通过官方媒体账号发布消息、作为指定代表参与在线或线下活动等。
+
+代表本项目的行为可由项目维护者进一步定义及解释。
+
+
+
+## 贯彻落实
+
+可以致信tc@openeuler.org，向项目团队举报滥用、骚扰及不当行为。
+
+维护团队将审议并调查全部投诉，妥善地予以必要的回应。项目团队有义务保密举报者信息。具体执行方针或将另行发布。
+
+未切实遵守或执行本行为标准的项目维护人员，经项目负责人或其他成员决议，可能被暂时或永久地剥夺参与本项目的资格。
+
+
+
+
diff --git a/community-membership.md b/community-membership.md
new file mode 100644
index 0000000000000000000000000000000000000000..0b03980f1d60f76058d337a3a8f434a1c8a0dd18
--- /dev/null
+++ b/community-membership.md
@@ -0,0 +1,125 @@
+# 社区成员
+
+
+本文简要描述了openEuler社区中贡献者角色的各种职责。大部分角色的职责限于这些SIG/项目内：
+
+| 角色        | 职责范围（简要描述）        | 要求                                                       | 定义的文件                                                   |
+| ----------- | --------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------ |
+| Contributor | 社区的积极贡献者            |                                                            | Gitee注册成员                                                |
+| Committer   | 审核其他成员的贡献          | SIG/项目的积极贡献者，经验丰富，愿意投入精力参与到审核工作 | openEuler SIG/项目拥有的存储库中OWNERS文件中的*Maintainer*条目。openEuler SIG/项目的openeuler.yaml中对应SIG/项目的*developer*条目 |
+| Maintainer  | SIG/项目或子SIG/项目的Owner | 经验丰富，富有责任心、出色的技术能力和沟通能力             | openEuler SIG/项目拥有的存储库中OWNERS文件中的*Maintainer*条目。openEuler SIG/项目的openeuler.yaml中对应SIG/项目的*developer*条目 |
+
+
+
+## 新的贡献者
+
+现有成员应该欢迎[新的贡献者](contributing.md)加入社区。我们有关于如何开始贡献的指导文档：
+
+- [openEuler贡献者指南](/contributors/guide/README.md)
+
+
+
+## 既有社区成员
+
+
+既有的社区成员应证明他们遵守本文中的原则，熟悉SIG/项目的组织、角色、政策、软件、约定等，以及相关的技术和/或写作能力。特性角色的期望、职责和要求，在下面列出。
+
+
+
+### 贡献者 Contributor
+
+-----
+
+贡献者是社区中持续活跃的贡献者，他们可以认领问题和PR，可以参与SIG/项目组活动，并且可以为PR提交前完成测试。
+
+
+
+#### 要求
+
++ Gitee上的注册会员
++ 为SIG/项目或社区做出多方面贡献，包括不限于：
+  + 在Gitee上提交或审核PR
+  + 在Gitee上对问题进行归档或评论
+  + 参与SIG/项目、子项目或社区讨论
+
++ 订阅dev@openeuler.org（社区开发公共邮件列表）
++ 已阅读[贡献者指南](/contributors/guide/README.md)
++ 积极参与1个或多个SIG/项目或子项目
+
+
+
+#### 责任与权利
+
++ 响应被分配的问题和PR
++ 贡献的代码应该
+  + 经过良好的测试
+  + 能够让测试用例始终通过
+  + 解决后继发生的错误或问题
+
++ 可以通过 `/lgtm`打开PR
++ 可以分配问题或PR，可以通过 `/cc @username`要求成员进行评论
++ 可以针对PR自动运行测试。`/ok-to-test`不是必要的
++ 可以使用`/ok-to-test`为具有`needs-ok-to-test`标签的PR进行操作，并使用诸如`/close`对PR进行关闭。
+
+**注意**：经常贡献代码的成员应积极的参与代码审查，并努力成为SIG/项目的*审核者*。
+
+
+
+## 审核者 Committer
+
+审核者能够在SIG/项目或某SIG/项目的某些部分中审核代码的质量和正确性。审核者对代码库和软件工程原理非常了解。
+
+定义者：openEulerSIG/项目拥有的存储库中OWNERS文件中的*developer*条目。
+
+### 要求
+
++ 作为贡献者至少3个月
++ 作为主要审阅者至少参与了6次PR的审阅
++ 审阅或合并至少20个基本PR到代码库
++ 熟悉代码库
++ 可以自我提名，或由该SIG/项目的审核者或维护者或由机器人提名
+
+### 责任与权力
+
++  **评审PR**：对Contributor提交的PR完成评审，评审可以参考社区的[编程建议]()和[安全编程规范]()。
++  **分发处理问题**，请参考“[问题处理流程]()“。
++  **跟踪依赖性问题**：在开发分支中，其他SIG/项目组的软件包的更新可能会到导致破坏本SIG/项目内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。
++  **如有接口变更，通知可能会影响到的SIG/项目**：其他SIG/项目或团队会依赖本SIG/项目，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG/项目。具体请参考[接口变更通知流程]()。
++  **更新和维护软件包版本**：遵守社区的[软件包更新质量控制策略](/group-pm/)完成软件包的更新。
++  **和上游社区合作**，包括：
+   +    将所有变更推送到上游社区
+   +    参与上游社区邮件列表
+   +    获取上游社区的bug跟踪器的账户，并跟踪上游社区的重要bug
+   +    将严重的错误转发给上游社区以寻求帮助
+         更多信息，请参考“[上游社区软件包管理建议]()”
++  **和测试团队合作**，包括：
+   +  在提交软件包时，向质量检查人员提供如何调试/分类软件包的信息，以供问题的分类
+   +  提供基本功能的测试用例，用于测试回归
+   +  提交软件包更新时，提供有关更新中已经修复问题的测试用例，以供质量检查人员使用。 
+
+
+
+## 维护者 Maintainer
+
+维护者是软件包的维护者，能够像Committer一样审查和批准代码贡献。代码审查的重点是代码质量和正确性，而批准的重点是对贡献的整体接受度。**所有Committer的责任与权力，Maintainer均具有**。除此之外，Maintainer还承担了团队的技术路线、内外协调等工作。
+
+**定义**：openEuler SIG/项目拥有的存储库中OWNERS文件中的*developer*条目
+
+
+
+### 要求
+
++ 作为审核者至少3个月
++ 作为主要审阅者至少参与了12次PR的审阅
++ 审阅或合并至少30个基本PR到代码库
++ 熟悉代码库
++ 可以自我提名，也可以由子项目Maintainer提名，并且没有其他子项目Maintainer的反对
+
+### 责任与权力
+
+- **确定SIG/项目的技术路线**：包括规划和决策SIG/项目技术方向、路标规划、架构演进。
+- **制定SIG/项目的发布计划**：确定SIG/项目的关键需求和发布计划；参与社区的PM活动，并协调SIG/项目计划和社区版本的里程碑时间表匹配
+- **参与社区协调活动**：作为SIG/项目的代表参与openEuler技术委员会或理事会组织的活动和特定会议等
+- **召集SIG/项目组会议**：定期召集SIG/项目组会议，决策SIG/项目组内上升的争议
+
+
diff --git a/zh/Gitee-Management/Gitee-management-guide.md b/zh/Gitee-Management/Gitee-management-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..f177e289ae4c505a4ecad6c06010511996ee7db2
--- /dev/null
+++ b/zh/Gitee-Management/Gitee-management-guide.md
@@ -0,0 +1,69 @@
+# openEuler Gitee组织管理指南
+
+openEuler项目使用Gitee来管理团队和代码。本指南包含如何在openEuler社区准则的基础上运作这些组织。
+
+
+
+## 服务承诺
+
+Gitee管理团队将竭尽所能提供以下的服务水平：
+
+- 新组织创建在所有成员资格满足以后的72小时内处理
+- Repository的新建或迁移请求在PR提交后的72小时内回复。这个过程可能需要申请人提供一些信息，所以可能会花费一些时间。但所有条件一旦满足，Gitee管理团队会在72小时内完成响应repository的处理
+- PR提交后的72小时内，会有所答复。问题解决的时间会按照问题的具体情况有所不同。
+
+如果您需要上报紧急请求，请直接联系[Gitee管理团队成员]()快速寻求帮助
+
+
+
+##  openEuler的组织说明
+
+- [openEuler]()：主要用于管理源代码类项目
+- [src-openEuler]()：主要用于存放制作发布件所需的制品仓库
+
+
+
+## 将外部代码转移到openEuler组织中
+
+由于开源许可和CLA等问题，在将软件包或/和代码转移到openEuler管理之前，需要进行一些调查，请先向[技术委员会]()提交申请.如已经拿到申请（包括新项目引入时获得的申请），XXXXXXXXXXXX
+
+
+
+## 团队指导
+
+### 团队角色和权限说明及配置方法
+
+
+
+
+
+### 处理过程
+
+- 创建新团队或项目请向技术委员会提交PR申请，请参考[项目治理](/../technical-committee/README.md)
+
+- 向团队添加新成员，请向[技术委员会]()提交PR申请，该PR可以由团队的`maintainer`批准
+
+  
+
+## repository使用指导
+
+repository还有license、CLA等要求，请参见[openEuler项目模板]()
+
+
+
+
+
+### 创建repository
+
+
+
+
+
+
+
+### 删除repository
+
+待补充
+
+
+
diff --git a/zh/Gitee-Management/README.md b/zh/Gitee-Management/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..c99f0d6dc6778871626bd30ae92916a581c6ffe0
--- /dev/null
+++ b/zh/Gitee-Management/README.md
@@ -0,0 +1,25 @@
+# Gitee 管理
+
+openEuler项目使用Gitee来存储和组织代码，管理问题和文档，并提供一致的贡献者流程。为了简化Gitee存储库的组织和管理。我们提供了一些工具来自动设置和执行管理策略。
+
+这些策略和工具的支持由基础设施下的Gitee管理团队负责。
+
+
+
+## 帮助指南
+
++ [向Gitee求助]()
++ [团队组织者指南]()
++ [Gitee权限说明]()
+
+
+
+
+
+
+
+## Gitee 管理团队介绍
+
+
+
+
diff --git a/zh/Gitee-Management/Repository.md b/zh/Gitee-Management/Repository.md
new file mode 100644
index 0000000000000000000000000000000000000000..e5127560f27e0813643c8be2c295bf45c7e30111
--- /dev/null
+++ b/zh/Gitee-Management/Repository.md
@@ -0,0 +1,168 @@
+# 仓库
+
+## 维护
+
+### 背景
+
+在openEuler社区有成百上个仓库。
+这是非常困难的去维护在每一个仓库中的所有成员。
+我们需要一个自动化的工具去解决这些问题从而节约团队的工作量。
+
+### 解决方案
+
+基础设施团队构建了一种机制去简化仓库的维护工作。
+所有openEuler的仓库和仓库成员都放在
+[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)文件中,
+而所有src-openEuler的仓库和仓库成员都放在
+[src-openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/src-openeuler.yaml)文件中。
+如果这些yaml文件被一个pull request所修改，`openeuler-ci-bot`将会检测到这些改变
+然后自动化地完成一些操作，例如`创建一个仓库`，`为一个仓库添加成员`，
+`从一个仓库移除成员`，`保护一个分支`，`移除一个保护分支`等基于Gitee API的操作。
+
+### 如何创建一个仓库
+
+``` yaml
+repositories:
+  - name: abattis-cantarell-fonts
+    description: "fonts repo"
+    type: private
+```
+
+如果你想要在openEuler社区里面新增一个仓库，
+你可以基于上面的示例提交一个pull request修改
+[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)
+或者[src-openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/src-openeuler.yaml)。
+
+* `abattis-cantarell-fonts`: 你想创建的新仓库名字。
+* `fonts repo`: 新仓库描述。
+* `private`: 表示仓库的类型。
+
+  `private`意味着新仓库只对某些特定的人群可见。
+
+  `public`意味着新仓库对所有人可见。
+
+一旦你的pull request被合入，```openeuler-ci-bot```将会立即创建一个新仓库。
+
+### 如何创建或者删除一个成员
+
+``` yaml
+community:
+  name: openeuler
+  managers:
+    - zhuchunyi
+    - overweight
+  developers:
+    - igorkorkin
+  viewers:
+    - jianminw
+repositories:
+  - name: abattis-cantarell-fonts
+    description: "fonts repo"
+    type: private
+  - name: accountsservice
+    description: "account repo"
+    type: private
+    managers:
+      - dogsheng
+    developers:
+      - igorkorkin
+    viewers:
+      - jianminw
+```
+
+如果你想要添加或者删除一个仓库的成员，
+你可以基于上面的示例提交一个pull request
+修改[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)
+或者[src-openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/src-openeuler.yaml)。
+
+* `openeuler`： openEuler组织名称， 另外还有一个组织`src-openeuler`，实际上不需要做修改。
+* `managers`：  你想在`community`或者`repositories`下指定的管理员。
+  这里需要Gitee账号，例如 `zhuchunyi`。
+* `developers`：你想在`community`或者`repositories`下指定的开发者。
+  这里需要Gitee账号，例如`igorkorkin`。
+* `viewers`: 你想在`community`或者`repositories`下指定的观察者。
+  这里需要Gitee账号，例如`jianminw`。
+
+***注意***：你可能已经发现`managers`，`developers`和`viewers`是同时存在于`community`和`repositories`。
+让我们来看看它们的不同之处：
+
+* 通常情况下你想要为所有仓库添加或删除一个管理员，开发者或者观察者，
+  你可以修改`community`下的`managers`，`developers`或者`viewers`。
+* 特定的情况下你想要为一个指定的仓库添加或删除一个管理员，开发者或者观察者，
+  你可以修改指定的仓库例如`accountsservice`下的`community`下的`managers`，`developers`或者`viewers`。
+* 如果一个仓库没有指定任何成员（包括`managers`，`developers`和`viewers`），例如`abattis-cantarell-fonts`仓库，
+  `openeuler-ci-bot`将会使用`community`下的`managers`，`developers`和`viewers`
+  来为这个仓库例如`abattis-cantarell-fonts`仓库创建成员。
+* 如果一个仓库指定了一些成员（包括`managers`，`developers`和`viewers`），例如`accountsservice`仓库，
+  `openeuler-ci-bot`将会使用这个仓库下的`managers`，`developers`和`viewers`
+  来为这个仓库例如`accountsservice`仓库创建成员。
+* 如果一个Gitee账号是存在于`managers`，`developers`和`viewers`之中，
+  这个Gitee账号将会是一个管理员，因为从Gitee的权限来讲，`managers` > `developers` > `viewers`。
+
+### 如何创建或者删除一个保护分支
+
+```yaml
+community:
+  name: openeuler
+  protected_branches:
+  - master
+repositories:
+  - name: abattis-cantarell-fonts
+    description: "fonts repo"
+    type: private
+  - name: accountsservice
+    description: "account repo"
+    protected_branches:
+    - master
+    - dev
+    type: private
+```
+
+如果你想要在一个仓库上创建或者删除一个保护分支，
+你可以基于上面的示例提交一个pull request
+修改[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)
+或者[src-openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/src-openeuler.yaml)。
+
+* `openeuler`：openEuler组织名称， 另外还有一个组织`src-openeuler`，实际上不需要做修改。
+* `protected_branches`：你想要在`community`或`repositories`创建的保护分支。
+
+***注意***：你可能已经发现`protected_branches`是同时存在于`community`和`repositories`。
+让我们来看看它们的不同之处：
+
+* 通常情况下你想要为所有仓库创建或删除一个保护分支，
+  你可以修改`community`下的`protected_branches`。
+* 特定的情况下你想要为一个指定的仓库添加或删除一个保护分支，
+  你可以修改指定的仓库例如`accountsservice`下的`community`下的`protected_branches`。
+* 如果一个仓库没有指定任何保护分支，例如`abattis-cantarell-fonts`仓库，
+  `openeuler-ci-bot`将会使用`community`下的`protected_branches`
+  来为这个仓库例如`abattis-cantarell-fonts`仓库创建保护分支。
+* 如果一个仓库指定了一些保护分支，例如`accountsservice`仓库，
+  `openeuler-ci-bot`将会使用这个仓库下的`protected_branches`
+  来为这个仓库例如`accountsservice`仓库创建保护分支。
+* 如果指定的`protected_branches`不存在，`openeuler-ci-bot`将会做任何动作。
+
+### 如何创建或者删除一个在Gitee之外的维护人员
+
+Gitee提供管理员、开发者和观察者等权限管理。
+`openeuler-ci-bot`支持另一种为每一个仓库添加维护人员的方式。
+`openeuler-ci-bot`将会扫描 `OWNERS`文件在每一个仓库下去发现额外的仓库维护人员。
+
+以`ci-bot`仓库下的 <https://gitee.com/openeuler/ci-bot/blob/master/OWNERS> 为例。
+文件内容如下：
+
+``` yaml
+maintainers:
+  - edisontest
+  - freesky-edward
+  - TommyLike
+  - xiangxinyong
+  - zerodefect
+```
+
+这意味着所有这5个用户具备在`ci-bot`仓库下合入pull request的权限。
+这些用户能使用`/lgtm`和`/approve`命令去触发`openeuler-ci-bot`何如pull request。
+你可以发现更多的命令说明 <https://gitee.com/openeuler/community/blob/master/zh/sig-infra/command.md>。
+顺便说下，所有的Gitee管理员和开发者也能使用`/lgtm`和`/approve`命令。
+
+如果你想要维护Gitee之外的仓库维护人员，请在你的仓库下添加`OWNERS`文件，
+然后添加仓库维护人员到`OWNERS`文件，`openeuler-ci-bot`将会给予这些仓库维护人员`合入`权限。
\ No newline at end of file
diff --git a/zh/Gitee-Management/opening-request.md b/zh/Gitee-Management/opening-request.md
new file mode 100644
index 0000000000000000000000000000000000000000..cd9427b1f5583d7b77f820d6a75d6b566ee1bbbe
--- /dev/null
+++ b/zh/Gitee-Management/opening-request.md
@@ -0,0 +1,28 @@
+# 如何向Gitee求助
+
+如果你需要了解和Gitee相关的以下内容，请向gitee管理团队求助
+
+- 权限问题
+- Gitee内的组织角色关系
+- 第三方集成
+- Reopsitory的新建和迁移
+- Repository的归档
+- 其他repository配置相关的问题
+
+请向[openEuler/sig-infrastructure]()提交你的issue。如果你的问题很紧急，请直接联系[Gitee管理团队的成员]()。
+
+创建新团队，添加新成员或者重命名您的团队，请根据[团队指南]()向[openEuler/technical-committee]()提交PR申请。
+
+
+
+## 社区biot/自动化问题
+
+如果您需要以下方面的帮助：
+
+- biot配置
+- 自动合并
+- 问题标签
+- 自动化反馈和功能需求
+
+请向[openEuler/sig-infrastructure]()提交你的issue。如果你的问题很紧急，请直接联系[Gitee管理团队的成员]()。
+
diff --git a/zh/Gitee-Management/permissions.md b/zh/Gitee-Management/permissions.md
new file mode 100644
index 0000000000000000000000000000000000000000..bdf98f93c6177dfc4dc81b122bd8a6859b9c98d4
--- /dev/null
+++ b/zh/Gitee-Management/permissions.md
@@ -0,0 +1,2 @@
+# Gitee 权限说明
+
diff --git a/zh/committee-product-security/README.md b/zh/committee-product-security/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..e64b7bb0f0a567cec0e94d091ccdcfd6c5eec424
--- /dev/null
+++ b/zh/committee-product-security/README.md
@@ -0,0 +1,48 @@
+# 产品安全委员会
+
+openEuler产品安全委员会是负责接收和响应openEuler产品安全问题报告的机构。该机构的使命是通过以下方式为openEuler用户提供最安全的操作环境：
+
++ 通过打包程序修复和更新软件包
++ 确定并帮助改善社区内的安全开发实践
++ 回答社区中的软件安全性相关问题
+
+
+
+## 工作职责
+
++ 协助漏洞修复：确保及时修补和发布已知漏洞。通过为软件包Maintainer们提供补丁帮助，帮助用户系统在成为攻击受害者之前进行漏洞修复，包括提供相关漏洞检测和修复工具。
++ 响应安全问题：响应上报的安全问题，跟踪安全问题的处理进展，并遵循安全问题披露策略对安全问题在社区内进行披露和公告。
++ 安全编码规则：防止漏洞被首先写入是安全团队的目标。安全团队会努力创建文档或开发工具来帮助开发团队避免软件开发过程中的常见陷阱。安全团队还会尝试回答过程中遇到的任何问题。
++ 参与代码审核：安全团队希望能够通过代码审核帮助团队提前发现代码中的漏洞。
+
+
+
+## 成员
+
++ XXXX（@XXX)
++ XXX
++ XXXX
++ XXXX
++ XXXX
+
+
+
+## 联系
+
++ 私人邮件列表：security@openEuler.org
++ 开放的社区ISSUE/PR
++ Gitee团队
+
+
+
+## 子项目
+
+### 安全
+
+产品安全委员会的政策和文件
+
++ 地址：XXXXXXXXXXXXXXXXXXXXXX
+
+  
+
+*如果要报告安全问题，请通过电子邮件发送到私人邮件列表：security@openEuler.org，其中包含安全问题的详细信息，以及所有openEuler错误报告的预期详细信息。*
\ No newline at end of file
diff --git a/zh/communication/IRCs.md b/zh/communication/IRCs.md
new file mode 100644
index 0000000000000000000000000000000000000000..a8168dfe3d8e2c7558adcecc7b003009c69fcdfd
--- /dev/null
+++ b/zh/communication/IRCs.md
@@ -0,0 +1,13 @@
+# openEuler IRC频道
+
+
+
+| IRC Channel          | description                      |
+| -------------------- | -------------------------------- |
+| #openeuler           | 每日讨论的公共频道               |
+| #openeuler-community | 社区行动计划的讨论频道           |
+| #openeuler-doc       | 文档团队的讨论频道               |
+| #openeuler-infra     | 社区基础设施和构建团队的讨论频道 |
+
+更多信息请登录 https://openeuler.org/en/community/irc.html 
+
diff --git a/zh/communication/Mails.md b/zh/communication/Mails.md
new file mode 100644
index 0000000000000000000000000000000000000000..f09c41bea81d39e8f15abe4a265f0b501db0d8fb
--- /dev/null
+++ b/zh/communication/Mails.md
@@ -0,0 +1,71 @@
+# openEuler的邮件列表
+
+###  加入邮件列表
+
+下表是当前可用的邮件列表。请按照您的兴趣加入：
+
+| Name                                                         | 地址                                                         | 类型   | 描述                                             |
+| ------------------------------------------------------------ | ------------------------------------------------------------ | ------ | ------------------------------------------------ |
+| [社区公告](https://mailweb.openeuler.org/postorius/lists/announce.openeuler.org/) | [announce@openeuler.org](mailto:announce@openeuler.org)      | 宣布   | 有关openEuler社区的主要公告，例如新闻和事件      |
+| [理事会](https://mailweb.openeuler.org/postorius/lists/council.openeuler.org/) | [council@openeuler.org](mailto:council@openeuler.org)        | 讨论区 | openEuler理事会和管理层的讨论。                  |
+| [社区](https://mailweb.openeuler.org/postorius/lists/community.openeuler.org/) | [community@openeuler.org](mailto:community@openeuler.org)    | 讨论区 | openeuler社区相关的主要讨论                      |
+| [开发](https://mailweb.openeuler.org/postorius/lists/dev.openeuler.org/) | [dev@openeuler.org](mailto:dev@openeuler.org)                | 讨论区 | 社区开发者之间的讨论                             |
+| [市场行销](https://mailweb.openeuler.org/postorius/lists/marketing.openeuler.org/) | [marketing@openeuler.org](mailto:marketing@openeuler.org)    | 讨论区 | 促进营销人员和组织者之间的讨论和最佳实践共享     |
+| [用户委员会](https://mailweb.openeuler.org/postorius/lists/user-committee.openeuler.org/) | [user-committee@openeuler.org](mailto:user-committee@openeuler.org) | 讨论区 | 用户提交电子邮件联系社区                         |
+| [基础设施](https://mailweb.openeuler.org/postorius/lists/infra.openeuler.org/) | [infra@openeuler.org](mailto:infra@openeuler.org)            | 讨论区 | 该社区的基础设施支持和交流                       |
+| [构建](https://mailweb.openeuler.org/postorius/lists/buildteam.openeuler.org/) | [buildteam@openeuler.org](mailto:buildteam@openeuler.org)    | 讨论区 | 为这个社区维护openEuler OS构建的团队的交流和讨论 |
+
+有两种加入列表的方法。
+
+**网页**
+
+> 1. 通过单击上表中的列表名称访问订阅页面
+> 2. 提供您的电子邮件地址，姓名并单击`Subscribe`按钮
+> 3. 登录您的电子邮件并直接回复来自openeuler.org的确认邮件
+
+当您收到`Welcome`邮件形式openeuler.org时，表明您已经在列表中。注意：如果您没有收到欢迎邮件，请保持标题与确认电子邮件相同，然后再次答复。
+
+**电子邮件**
+
+> 1. 将带有主题（标题）的电子邮件发送到列表`subscibe address`（列表地址后缀为）。`-join``subscribe`
+> 2. 直接回复来自openeuler.org的确认电子邮件。
+
+订阅电子邮件的示例是Dev（[dev@openeuler.org](mailto:dev@openeuler.org)）：
+
+```
+接收者：dev-join@openeuler.org 
+主题：订阅
+内容：不适用
+```
+
+
+
+### 发送邮件
+
+公告和讨论列表有两种，对于讨论，发送电子邮件到列表和发送到其他私人地址之间没有任何区别，只需按常规发送，在方括号（[dev]）中添加带有频道名称的前缀即可，但这不是强制性的。
+
+注意 ，“公告”仅用于发布消息或通知，它不接受任何邮件传递。
+
+注意：如果您无法在收件箱中收到任何邮件，请首先查看您的垃圾邮件设置。
+
+
+
+### 离开邮件清单
+
+如果要离开加入的邮件列表，请执行以下步骤：
+
+> 1. 发送带有主题的电子邮件至`unsubscribe address`（带有的列表addreess子修补程序`-leave`）`unsubscribe`。
+> 2. 不做任何修改的回复确认邮件，。
+
+收到取消订阅的电子邮件后，您将不在列表中。
+
+
+
+### 得到帮助
+
+如果遇到任何问题，请通过以下方式联系基础架构团队：
+
+- 电子邮件：[infra@openeuler.org](mailto:infra@openeuler.org)
+- IRC：＃openEuler-infra（待定义）
+
+如果您发现任何与问题相关的邮件列表，请随时在[基础架构中](https://gitee.com/openeuler/infrastructure/issues)打开一个问题
\ No newline at end of file
diff --git a/zh/communication/README.md b/zh/communication/README.md
index d7e746fcfda1998223c9e1d78b7e307a37c2fe4e..fd4b22e676da776af00dbf9887c9c1ef53fd37ab 100644
--- a/zh/communication/README.md
+++ b/zh/communication/README.md
@@ -1,8 +1,16 @@
 # 社区沟通和交流
 
-## 本文档的目的
-
 openEuler包含许多项目，这些项目被组织成社区团体。这些团体的沟通和交流渠道，包括邮件列表、IRC频道等，并且可以在这些团队的README上找到。
 
 
-*todo*：下面描述如何使用社区的通信
+
+## IRC 聊天室
+
+对于每个团队和信号，我们建议使用IRC频道作为基本的通讯聊天工具。在[IRC频道](https://gitee.com/openeuler/community/blob/master/zh/IRCs.md)中列出了所有通道，选择一个或多个和自由免费加入他们的行列。
+
+
+
+##  邮件
+
+如果要开始一个开放主题的讨论，将电子邮件发送到相关的邮件列表是另一个不错的选择。在[邮件列表中](https://gitee.com/openeuler/community/blob/master/cn/Mails.md)列出了所有的邮件列表
+
diff --git a/zh/contributors/Gitee-workflow.md b/zh/contributors/Gitee-workflow.md
index dc83a85860b864b20cf385f0e7dc77881922c69d..954d210690c890631b31402de506736b0773110c 100644
--- a/zh/contributors/Gitee-workflow.md
+++ b/zh/contributors/Gitee-workflow.md
@@ -1,10 +1,12 @@
-
+# Gitee 工作流说明
 
 ### 1.从云上folk
 
 1. 访问 https://gitee.com/openEuler/openEuler
 2. 点击右上角的 `Fork` 按钮建立一个属于自己的云上folk分支
 
+
+
 ### 2.把folk分支复制到本地
 
 请按照以下的复制过程将openEuler的代码下载到您的在计算机上。
@@ -51,6 +53,8 @@ git remote set-url --push upstream no_push
 git remote -v
 ```
 
+
+
 ### 3.拉分支
 
 更新您的本地分支
@@ -86,6 +90,8 @@ git rebase upstream/master
 
 执行merge的时候，请不要使用 `git pull` 替代上面的 `fetch` / `rebase`. `git pull` 。因为这种方式会使提交历史变得混乱，并使代码更难被理解。您也可以通过更改文件来达到目的， `.git/config` 文件通过 `git config branch.autoSetupRebase always` 去改变 `git pull`的行为。
 
+
+
 ### 5 提交
 
 提交您的更改。
diff --git a/zh/contributors/README.md b/zh/contributors/README.md
index 46d4663271d56ac5e9ff4cecb19704cdb1626494..886b118134fe0d61570b5acc7440a7c3ad625ca7 100644
--- a/zh/contributors/README.md
+++ b/zh/contributors/README.md
@@ -1,4 +1,6 @@
-该文档指导大家如何为openEuler的代码库做出贡献。欢迎阅读[待解决的问题]()并提出新的问题。
+该文档指导大家如何为openEuler社区做出贡献。欢迎阅读[待解决的问题]()并提出新的问题。
+
+
 
 # 欢迎
 
@@ -11,116 +13,130 @@
   + [社区期望](#id1-3)
 - [您的第一个贡献](#id2)
   - [找到您感兴趣的工作](#id2-1)
-    - [了解SIG](#id2-1-1)
-    - [找到您感兴趣的SIG组合respository](#id2-1-2)
+    - [了解SIG/项目](#id2-1-1)
+    - [找到您感兴趣的SIG/项目和respository](#id2-1-2)
   - [开始您的贡献](#id2-2)
     - [给你自己分配一个issue](#id2-2-1)
     - [提出问题](#id2-2-2)
-    - [SIG贡献者指南](#id2-2-3)
+    - [SIG/项目贡献者指南](#id2-2-3)
     - [社区贡献指导](#id2-2-4)
-  - [沟通](#id2-3)
+  - [沟通](id2-3)
 - [Gitee工作流程](#id3)
-- [提交一个PR](#id4)
-- [代码检视](#id5)
-- [测试](#id6)
-- [选择社区组件打包](#id7)
-- [下载安装openEuler](#id8)
-- [安全](#id9)
-- [社区文档](#id10)
-- [社区活动](#id11)
-  - [社区交流](#id11-1)
-  - [大事记](#id11-2)
-  - [聚会](#id11-3)
+- [代码检视](#id4)
+- [测试](#id5)
+- [选择社区组件打包](#id6)
+- [下载安装openEuler](#id7)
+- [安全](#id8)
+- [社区文档](#id9)
+- [社区活动](#id10)
+  - [社区交流](#id10-1)
+  - [大事记](#id10-2)
+  - [聚会](#id10-3)
+
+
 
-<h1 id=“id1”>开始之前</h1>
 
+<h1 id=“id1”>开始之前</h1>
 <h2 id="id1-1">签署CLA</h2>
+您必须首先签署[“贡献者许可协议”（CLA）](/../../CLA.md)，然后才能参与社区贡献.
+
 
-您必须首先签署[“贡献者许可协议”（CLA）](../CLA.md)，然后才能做出贡献.
 
 <h2 id="id1-2">行为守则</h2>
+请确保阅读并遵守openEuler社区的[行为守则](/../../code-of-comduct.md)。
+
 
-请确保阅读并遵守openEuler社区的[行为守则](/../code-of-comduct.md)。
 
 <h2 id="id1-3">社区期望</h2>
+openEuler是一个开源社区。因此它完全依赖于社区提供开发，以及友好和协作的环境，请查看[社区成员角色](/../community-membership.md)。社区鼓励您在积累经验的同时提高你的贡献级别。
+
 
-openEuler是一个开源社区项目。因此它完全依赖于社区提供开发，以及友好和协作的环境，请查看[社区成员角色](/../community-membership.md)。社区鼓励您在积累经验的同时提高你的贡献级别。
 
 <h1 id="id2">您的第一个贡献</h1>
+随时欢迎您的加入！在社区上总是有可以改进的文档（比如您正在阅读的），可以澄清的代码，可以重构或注释的函数或变量，始终需要测试的代码。我们将帮助您了解openEuler SIG/项目的组织方式，并引导您顺利的开始您的第一个贡献。您可以选择解决问题、编写代码，或者检视和合并等工作。所以如果您感兴趣，现在就行动吧~~
+
+如果您对开发过程有疑问，请随时加入我们的[邮件列表](dev@openeuler.org)，并在邮件标题内用“【开发过程疑问】”作为标题 写出你的疑问和困惑，openEuler团队会定期扫描邮件列表上的内容，并尽力确保您的问题得到解答。
 
-随时欢迎您的加入！在社区上总是有可以改进的文档（比如您正在阅读的），可以澄清的代码，可以重构或注释的函数或变量，始终需要测试的代码。我们将帮助您了解openEuler项目的组织方式，并引导您顺利的开始您的第一个贡献。您可以选择解决问题、编写代码，或者检视和合并等工作。所以如果您感兴趣，现在就行动吧~~
 
-如果您对开发过程有疑问，请随时加入我们的XXXX或加入我们的[邮件列表]()。您也可以在XXXX或XXXX上提问，openEuler团队会定期扫描XXX上的内容，并尽力确保您的问题会得到解答。
 
 <h2 id="id2-1">找到您感兴趣的工作</h2>
+<h3  id="id2-1-1">了解SIG/项目</h3>
+#### SIG/项目和Repository
 
-<h3  id="id2-1-1">了解SIG（Special Interest Group）</h3>
+我们将社区按照不同的SIG/项目来组织，以便于更好的管理和改善工作流程。
 
-#### SIG和Repository
+SIG/项目组是开放的，欢迎任何人加入并参与贡献。SIG/项目组内部会定期开会，每一个SIG/项目都有一个公共频道。每一个SIG/项目在Gitee上都会拥有一个repository，单击SIG/项目名称中的链接，可以获取每个SIG/项目的`README.md`。在`README.md`里可以查找到SIG/项目包含的子项目。每一个SIG/项目在Gitee上也会拥有至少一个repository。
 
-我们将社区按照不同的SIG来组织，以便于更好的管理和改善工作流程。
 
-SIG是开放的，欢迎任何人加入并参与贡献。SIG会定期开会，每一个SIG都有一个公共频道。每一个SIG在Gitee上都会拥有一个repository，单击SIG名称中的链接，可以获取每个SIG的`README.md`。在`README.md`里可以查找到SIG的子项目，每一个SIG都至少有一个子项目。每一个子项目在Gitee上也会拥有一个repository。
 
-<h3 id="id2-1-2">找到您感兴趣的SIG组和repository</h3>
+<h3 id="id2-1-2">找到您感兴趣的SIG/项目组和repository</h3>
+找到适合您贡献的SIG/项目组，可以帮助您在正确的地方提出问题，为您的贡献提供更高的知名度和更快的社区响应速度。您可以查看[SIG/项目列表](/../SIG&project-list.md)，以便您最快速的定位到自己感兴趣的领域。
 
-找到适合您贡献的SIG组，可以帮助您在正确的地方提出问题，为您的贡献提供更高的知名度和更快的社区响应速度。您可以查看[SIG列表](/../SIG-list.md)，以便您最快速的定位到自己感兴趣的领域。由于SIG不会直接映射子项目的repository，需要您在SIG列表内获取到子项目名称后，在openEuler的Repository列表下搜索子项目名称，就可以找到对应子项目的repository。如果搜索不到，您可以尝试在[XXXX]()中寻求帮助。
+在openEuler的Repository列表下搜索SIG/项目名称，也可以找到对应子SIG/项目的repository。如果搜索不到，您可以尝试在dev@openeuler.org中寻求帮助。同样，请在邮件列表内用“【开发过程疑问】”作为标题 写出你寻找的SIG或项目。
 
-<h2 id="id2-2">开始您的贡献</h2>
 
-找到您感兴趣的SIG或子项目的repository后，您会发现在repository内有可以拉取的代码，也有适合初学者的issue，还有交付成果的产品文档。您可以在repository中找到文档方面的改进需求，通过改进文档的过程，您也可以熟悉社区的代码提交/构建检查/合并等过程。详细可以参阅下面的[贡献](目录)以了解工作流程。
+
+<h2 id="id2-2">开始您的贡献</h2>
+找到您感兴趣的SIG/项目的repository后，您会发现在repository内有可以拉取的代码，也有适合初学者的issue，还有交付成果的产品文档。您可以在repository中找到文档方面的改进需求，通过改进文档的过程，您也可以熟悉社区的代码提交/构建检查/合并等过程。详细可以参阅本文以了解工作流程。
 
 如果您的兴趣不在编写代码方面，可以在[《非代码贡献指南》](non-code-contributors.md)中找到感兴趣的工作。
 
-<h3 id="id2-2-1">给自己分配一个issue</h3>
 
+
+<h3 id="id2-2-1">给自己分配一个issue</h3>
 如果您愿意处理一个issue，可以将它分配给自己。只需要在评论框内输入 `/assign`或 `/assign @yourself`，机器人就会将问题分配给您，您的名字将显示在负责人列表里。
 
+
+
 <h3 id="id2-2-2">提出问题</h3>
+尽管社区鼓励每个人贡献代码，但是当您报告问题或缺陷的时候，也是值得赞赏的。问题应提交到对应的repository下面。您可以查看[问题提交指南](issue-submit.md)以获取更多的信息。提交问题时，请确保遵守问题提交准则。
 
-尽管社区鼓励每个人贡献代码，但是当您报告问题或缺陷的时候，也是值得赞赏的。问题应提交到对应的repository下面。可以查看[问题分类指南]()以获取更多的信息。提交问题时，请确保遵守问题提交准则。
-当您不确定您要提交的问题是属于哪个repository时，您可以把你的问题提交到社区的[公共问题repository](https://gitee.com/openeuler/community-issue/issuess)
 
-<h3 id="id2-2-3">SIG贡献指南</h3>
 
-每个SIG组或子项目的编码语言、开发环境、编码约定等都可能是由差异的。所以每一个SIG或其子项目都可能有自己的贡献者指南——一般是`CONTRIBUTING.md`文件。除了这些文件外，SIG可能还会提供其他指南信息。这些信息位于SIG或子项目的特定社区目录中。请参考每个项目组详细的[SIG贡献者指南清单](Prj&SIG-contributor-list)。比如：
+<h3 id="id2-2-3">SIG/项目贡献指南</h3>
+每个SIG/项目或子项目的编码语言、开发环境、编码约定等都可能是由差异的。所以每一个SIG/项目或其子项目都可能有自己的贡献者指南——一般是`CONTRIBUTING.md`文件。除了这些文件外，SIG/项目可能还会提供其他指南信息。这些信息位于SIG/项目或子项目的特定社区目录中。
+
+
 
 <h3 id="id2-2-4">社区贡献指导</h3>
+初学者也可以通过下面的[提交PR](pull-request.md)和[代码检视](expectation.md)中找到相关指导。
+
+
 
-初学者也可以通过下面的[提交一个PR](#id4)和[代码检视](#id5)中找到相关指导。为了快速给您全面的指导，我们还提供了一个方便的[贡献者备忘录]()。
 
 <h2 id="id2-3">沟通</h2>
+openEuler是开源的，我们希望围绕开发建立一些半正式的管理规则，这样可以使事情开展的更加顺利。如果您认为这些规则有问题，请提出来。作为潜在的贡献者，无论是在白天、黑夜、工作日、周末或节假日，不要犹豫，我们都欢迎您提出自己的想法到dev@openeuler.org。我们致力于改善您的贡献体验。如果您发现不良的参与体验，请告诉我们！
 
-openEuler是开源的，我们希望围绕开发建立一些半正式的管理规则，这样可以使事情开展的更加顺利。如果您认为这些规则有问题，请提出来。作为潜在的贡献者，无论是在白天、黑夜、工作日、周末或节假日，不要犹豫，我们都欢迎您提出自己的想法。
 
-sig-contributor整个SIG组也致力于改善您的贡献体验。如果您发现不良的参与体验，请告诉我们！当然，更好的方式是通过加入这个SIG组来帮助我们解决此类问题。
 
 <h1 id="id3">Gitee工作流程</h1>
+想获取要使用的代码，请参考[Gitee workflow Guide](/Gitee-workflow.md)。
 
-想获取要使用的代码，请参考[Gitee workflow Guide](Gitee-workflow.md)。
-
-<h1 id="id4">提交一个PR</h1>
+### 提交一个PR
 
-openEuler遵循标准的[Gitee PR请求流程](https://gitee.com/help/articles/4128)，但openEuler社区还做了部分的定制，请参考[openEuler社区Gitee工作流程](Gitee-workflow.md)。
+openEuler遵循标准的[Gitee PR请求流程](https://gitee.com/help/articles/4122)，但openEuler社区还做了部分的定制，请参考[openEuler社区Gitee工作流程](pull-request)。
 
-这两个流程的主要区别是，openEuler的机器人会将结构化标签运用于PR中。该机器人可以为您的PR过程提供一些有用的建议。为了方便查看，可以在注释中输入命令，以触发自动标记和通知功能。请参阅[社区命令参考文档](../sig-infra/command.md)。
+这两个流程的主要区别是，openEuler的机器人会将结构化标签运用于PR中。该机器人可以为您的PR过程提供一些有用的建议。为了方便查看，可以在注释中输入XXXXXXX选项，以触发自动标记和通知功能。请参阅[社区命令参考文档](command.md)。
 
 对于新贡献者来说，常遇到的问题是：
 
-+ 在您的第一个PR之前没有正确的签署CLA（请参阅[签署CLA](#id1-1)）
-+ 为PR在项目组内找到合适的检视者，并保证自己的贡献遵循项目组内特定的贡献准则（请参阅[了解SIG](#id2-1-1)）
-+ 处理在PR上失败的测试用例，这些测试用例可能与您引入的更改无关
++ 在您的第一个PR之前没有正确的签署CLA（请参阅[签署CLA](/../../CLA.md）
++ 为PR在SIG/项目组内找到合适的检视者，并保证自己的贡献遵循SIG/项目组内特定的贡献准则（请参阅[了解SIG/项目]()）
++ 处理在PR上失败的测试用例，这些测试用例可能与您引入的更改无关（请参阅）
 + 不遵守一些[良好的编码实践]()
-+ 在提交的信息中包含了可能关闭issue的关键字，比如`/close`等
++ 在提交的信息中包含了可能关闭issue的关键字，比如XXXXXXXX等
 
-<h1 id="id5">代码检视</h1>
 
+
+<h1 id="id4">代码检视</h1>
 对于贡献者，关于代码检视的重要性的简要说明，请参阅[代码检视](expectation.md)。为了使您的提交更容易被接受，您需要：
 
-+ 遵循项目组的[编码约定](coding-conventions.md)
++ 遵循SIG/项目组的[编码约定](coding-conventions.md)
 + 准备完善的提交信息
 + 如果一次提交的代码量较大，建议将大型的内容分解成一系列逻辑上较小的内容，分别进行提交会更便于检视者理解您的想法
-+ 使用适当的项目组和监视者标签去标记PR：机器人会发送给您消息，以方便您更好的完成整个PR的过程
++ 使用适当的SIG/项目组和监视者标签去标记PR：机器人会发送给您消息，以方便您更好的完成整个PR的过程
+
+
 
 对于检视者，强烈建议本着[行为准则](/../code-of-conduct.md)和[社区期望](/expectations.md)，超越自我，相互尊重和促进协作。在审查其他人的PR的时候，[补丁审核的柔和艺术](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/)提出了一系列检视的重点，旨在说明检视的活动也希望能够促进新的贡献者积极参与，而不会使贡献者一开始就被细微的错误淹没，所以检视的时候，可以重点关注包括：
 
@@ -130,49 +146,56 @@ openEuler遵循标准的[Gitee PR请求流程](https://gitee.com/help/articles/4
 
 注意：如果您的PR请求没有引起足够的关注，可以在XXXXX的XXXXX频道来获取查找评论者们的帮助。
 
-<h1 id="id6">测试</h1>
 
-测试——是所有贡献者的责任，对于社区版本来说，SIG-Testing项目组也会做很多的协调工作。有关的信息信息，可以参考[《测试指南》](/../sig-test/testing.md)
+
+<h1 id="id5">测试</h1>
+测试——是所有贡献者的责任，对于社区版本来说，sig-qa也会做很多的协调工作。有关的信息信息，可以参考[《测试指南》](/../sig-test/testing.md)
 
 为了成功发行一个社区版本，需要完成多种测试活动。不同的测试活动，测试代码的位置也有有所不同，成功运行测试所需的环境的细节也会有差异：
 
+todo：待qa团队补充具体的测试活动内容
+
 + 单元测试：这一测试活动确定特性功能的行为是否符合预期。XXXXXXXXXXXXXXXX，可以在给定包中与相应源代码的相邻位置找到单元测试的源代码。例如XXXXXXXX中定义的函数将在XXXXXXXXXX中进行单元测试。
 + XXXX测试
 + XXXX测试
-+ XXXX测试
 
 持续集成会将这些测试活动在PR提交前完成，结果会出现在XXXX上
 
-sig-testing项目组是负责测试活动的官方机构，他们的相关测试自动化工具在test-fra中。如果您你希望自己的基础架构上能运行XXX测试，可以考虑采用。
+[sig-qa组]()是负责测试活动的官方机构，他们的相关测试自动化工具在test-fra中。如果您你希望自己的基础架构上能运行XXX测试，可以考虑采用。
 
-<h1 id="id7">选择社区组件打包</h1>
 
+
+<h1 id="id6">选择社区组件打包</h1>
 请参考[如何打包](packaging.md)
 
-<h1 id="id8">安装openEuler</h1>
 
+
+<h1 id="id7">安装openEuler</h1>
 请参考[下载安装openEuler](https://openeuler.org/zh/docs/installation/installation.html)
 
-<h1 id="id9">安全</h1>
 
+
+<h1 id="id8">安全</h1>
 + [安全发布页面]()——简要描述了处理安全问题的过程
 + [安全披露信息]()——如果您希望报告安全漏洞，请参考此页面
 
-<h1 id="id10">社区文档</h1>
 
+
+<h1 id="id9">社区文档</h1>
 + [贡献文档]()
 
-<h1 id="id11">社区活动</h1>
 
-<h2 id="id11-1">交流</h2>
 
+<h1 id="id10">社区活动</h1>
+<h2 id="id10-1">交流</h2>
 [社区常规交流方式](/../communication)
 
-<h2 id="id11-2">大事记</h2>
 
-openEuler参加了XXXXXX，每年在XXXXXXX，关于这些事件和其他社区事件信息可以在[openEuler未来事件](https://openeuler.org/zh/events.html)页面上找到。
 
-<h2 id="11-3">聚会</h2>
+<h2 id="id10-2">大事记</h2>
+openEuler参加了XXXXXX，每年在XXXXXXX，关于这些事件和其他社区事件信息可以在[openEuler事件]()页面上找到
+
+
 
-我们遵循针对开发者的聚会的XX
-XXX准则，您可以通过XXXXX上的直接消息或通过电子邮件(XXXX@huawei.com)与XXXX联系。来加入我们吧~
+<h2 id="10-3">聚会</h2>
+我们遵循针对开发者的聚会的XXXXX准则，您可以通过XXXXX上的直接消息或通过电子邮件(XXXX@huawei.com)与XXXX联系。来加入我们把~
\ No newline at end of file
diff --git a/zh/contributors/coding-conventions.md b/zh/contributors/coding-conventions.md
new file mode 100644
index 0000000000000000000000000000000000000000..23b32f0a329786c2323e824818fd087b72e51c38
--- /dev/null
+++ b/zh/contributors/coding-conventions.md
@@ -0,0 +1,2 @@
+# 编码约定（C/C）
+
diff --git a/zh/contributors/expectations.md b/zh/contributors/expectations.md
new file mode 100644
index 0000000000000000000000000000000000000000..90bddc649ccaf38b7cfde2330627f9dc39c0fbae
--- /dev/null
+++ b/zh/contributors/expectations.md
@@ -0,0 +1,14 @@
+## 代码检视指南
+
+首先感谢所有为openEuler成为一个成功的操作系统，以及一个成功的社区付出时间和精力的人们。
+
+openEuler的愿景是：**通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统openEuler，推动软硬件生态繁荣发展**。
+
+
+
+本文描述了我们对openEuler社区成员的期望。它涵盖了对所有成员的行为期望以及所有积极贡献者的代码检视期望。
+
+
+
+代码检视
+
diff --git a/zh/contributors/installation.md b/zh/contributors/installation.md
new file mode 100644
index 0000000000000000000000000000000000000000..ca47e44b7d33d580d8c41e6ff1a190bb55c0988e
--- /dev/null
+++ b/zh/contributors/installation.md
@@ -0,0 +1,3 @@
+# 安装指南
+
+[todo]待提供
\ No newline at end of file
diff --git a/zh/contributors/issue-submit.md b/zh/contributors/issue-submit.md
new file mode 100644
index 0000000000000000000000000000000000000000..ea10d100201099ec06feb6a99ce7dad3ff669c30
--- /dev/null
+++ b/zh/contributors/issue-submit.md
@@ -0,0 +1,63 @@
+# 问题提交指南
+
+发现并提交问题，也是对社区良好的贡献方式。
+
+本文详细描述如何提交一个良好的问题。
+
+
+
+### 确认问题所属的SIG或项目组
+
+- 如果您能够确定问题归属于哪一个SIG或项目组，请在repository的搜索栏找到该SIG或项目组的repository。
+- 如果您不能确定问题归属，请点击“[community-issue](https://gitee.com/openeuler/community-issue)”repository
+
+
+
+### 创建一个新的issue
+
+1、点开对应的repository后，在repository的工具栏内点击“Issue”，再点击创建“+新建Issue”按钮。
+
+2、将新ISSUE的标题栏内的问题类型选择为“缺陷”
+
+3、在标题栏内简要描述一下问题的现象和影响
+
+4、在详细描述框下，请按照模板说明问题发生的细节，如下：
+
+```
+**【环境信息】**
+硬件信息
+- 裸机场景请提供问题的硬件信息
+- 虚拟机场景请提供虚拟机的XML文件或配置信息
+软件信息
+- OS版本及分支信息
+- 内核信息
+- 发现问题的组件版本信息
+网络信息
+- 如果有特殊组网，请提供网络拓扑信息
+
+**【问题复现步骤】**，请描述具体的操作步骤
+**【实际结果】**，请描述出问题的结果和影响
+**【其他相关附件信息】**
+比如系统message日志/组件日志、dump信息、图片等
+```
+
+
+
+### 提交并配合问题处理
+
+您提交问题以后，如果问题的描述和复现步骤清晰明确和可定位，会有人直接定位和解决该问题。但也有可能会出现，负责跟进该问题的开发者需要您提供更加详细的信息的情况，也感谢您的配合。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/zh/contributors/non-code-contributions.md b/zh/contributors/non-code-contributions.md
new file mode 100644
index 0000000000000000000000000000000000000000..0966ff878fc752905b280d79620bfee3b8a542ab
--- /dev/null
+++ b/zh/contributors/non-code-contributions.md
@@ -0,0 +1,49 @@
+# 非代码类贡献
+
+下面的列表旨在帮助非代码贡献者找到openEuler社区项目中可以利用其专业知识的最佳领域。这样不仅是为希望参与贡献的任何人提供了入门指南，而不必限于编码，还可以满足项目组当前可能无法由专注于代码贡献者完成的任何需求。您对以下的项目或角色感兴趣，都可以联系我们！
+
+
+
+## 外向型社区工作
+- 参与[社区交流](/../communication)，包括帮助引导社区新人贡献社区，回答社区上的疑问等，
+- 运维社区通信工具，包括联系主持社区会议等
+- 共同组织社区聚会，包括openEuler开发者大会等，
+- 管理社区“大事件”等，包括查看管理讨论中的事件
+- 参与社区非文件的写作，包括社区推广、安装手册、博客和视频等
+
+
+
+## 内向型社区工作
+
+- 参与社区文档写作
+- 参与社区版本测试验证，请加入sig-test，参考该SIG的[README]()和贡献者相关的指导。
+- 参与社区基础设施建设，请加入sig-infrastructure
+- 参与社区视觉设计，请加入sig-ucd
+
+  
+
+## 项目组内的特定角色
+
+以下的角色对于openEuler中的每一个项目或SIG都很重要。如果您对项目中的特定主体感兴趣，可以通过多种不同的方式为特定的项目组做出贡献。
+
+- 文献资料
+  - 项目/SIG专业知识领域的通用文档
+  - 更新，审查和记录文档
+  - 翻译
+
+- UX/UI设计
+- 打包发布
+- 项目管理
+  - 确认任务、问题等的所有权
+  - 管理PR，管理项目组分类和标签，编辑PR相关文本
+  - 为项目/SIG等组织和帮助召开会议
+
+
+
+### 具备基本代码能力的非代码任务
+
+以下角色不写代码，但需要具有基本的编码知识或编码相关特定领域知识。
+
+- 产品文档
+- 管理发行说明
+- 项目内Github管理（存储库管理）
\ No newline at end of file
diff --git a/zh/contributors/packing.md b/zh/contributors/packaging.md
similarity index 100%
rename from zh/contributors/packing.md
rename to zh/contributors/packaging.md
diff --git a/zh/contributors/pull-requests.md b/zh/contributors/pull-requests.md
new file mode 100644
index 0000000000000000000000000000000000000000..9f6a4a2fc29bed7a63bed07b9f6442a08a12cd13
--- /dev/null
+++ b/zh/contributors/pull-requests.md
@@ -0,0 +1,71 @@
+# PR提交指南
+
+本指南确保您的PR请求符合我们的最佳实践。
+
+
+
+## 在提交PR请求之前
+
+请您在提交PR之前完成本地验证，以便在一定程度上保证在提交PR后的持续集成测试的通过。
+
+XXXXXXXXXXXX（todo：此处需提供在本地完成测试的方法）
+
+
+
+
+
+## 提交PR
+
+### PR提交工作流
+
+1、提交PR请求
+
+2、机器人分配评审人
+
+3、运行自动化测试。
+
+- 如果测试成功
+- 如果测试失败，则XXXXXXXXXXX
+
+4、审核人对提交进行审核
+
+5、将审核意见推送给您的PR分支
+
+6、根据需要重复前两个步骤。直到评审者添加``标签。该标签说明，该评审者已经认为本次的PR提交内容，已经通过该评审人的审核。
+
+7、机器人分配的审批者会根据评审人意见，以及自己的评审意见添加``标签，表示本次PR提交通过最终审核，并准备自动合并。
+
+
+
+### 关于`Test-Ready`
+
+- 组织成员可以将`test-ready`标签应用到贡献者提交的PR，以表明可以对该PR进行测试
+
+
+
+### 标记未完成的PR请求
+
+如果您想在PR请求完成之前先征求大家的意见，有两种方法可以实现此目的：
+
+1、您可以添加`hold`或`hold-cancel`注释
+
+2、您可以在PR请求的标题中添加或删除`WIP`或`[WIP]`前缀
+
+当存在这两个标签时，将不会考虑合并你的PR请求。
+
+
+
+### PR请求和发布周期
+
+如果您的PR请求已经通过审核，但是一直未合入，则可能是由于当前出去版本的发布周期处于特定阶段造成的。有时版本致力于解决特定的问题或达成特定的目标，可能会冻结代码库的合入。
+
+如果您认为此种状态不合理，可以联系对应的SIG/项目或[sig-pm]()进行澄清。
+
+
+
+### 注释命令参考
+
+请参考[命令行文档](/.../../sig-frastructure/Comand.md)
+
+
+
diff --git a/zh/sig-infrastructure/Command.md b/zh/sig-infrastructure/Command.md
new file mode 100644
index 0000000000000000000000000000000000000000..a673b6ed25f23dc788b4112f3d8efc3a62a1e520
--- /dev/null
+++ b/zh/sig-infrastructure/Command.md
@@ -0,0 +1,17 @@
+#  OpenEuler社区命令参考文档
+
+openEuler社区的所有项目都由Bot维护。 这意味着开发人员可以在每个Pull Request或Issue下面进行回复来触发Bot命令。 这些命令包括：
+
+| 命令               | 示例                                  | 描述                                                         | 谁能使用                                                     |
+| ------------------ | ------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| /check-cla         | /check-cla                            | 强制重新检查一个Pull Request的CLA状态。 如果Pull Request的作者已经签署CLA， 这个Pull Request将会新增一个名为`openeuler-cla/yes`的标签， 反之将会新增一个名为`openeuler-cla/no`的标签。 | 任何人                                                       |
+| /lgtm [cancel]     | /lgtm /lgtm cancel                    | 为一个Pull Request添加或者删除`lgtm`标签，这个标签将用于Pull Request合入判断。 | 这个仓库的协作者。Pull Request能使用`/lgtm cancel`命令，但是不能使用`/lgtm`命令。 |
+| /approve [cancel]  | /approve /approve cancel              | 为一个Pull Request添加或者删除`approved`标签，这个标签将用于Pull Request合入判断。 | 这个仓库的协作者。                                           |
+| /[remove-]kind     | /kind bug /remove-kind bug            | 添加或者删除这种kind类型的标签。 例如：`kind/bug`标签。      | 任何人都能在一个Pull Request或者Issue上触发这种命令。        |
+| /[remove-]priority | /priority high /remove-priority high  | 添加或者删除这种priority类型的标签。 例如：`priority/high`标签。 | 任何人都能在一个Pull Request或者Issue上触发这种命令。        |
+| /[remove-]sig      | /sig kernel /remove-sig kernel        | 添加或者删除这种sig类型的标签。 例如：`sig/kernel`标签。     | 任何人都能在一个Pull Request或者Issue上触发这种命令。        |
+| /close             | /close                                | 关闭一个Pull Request或者Issue。                              | 作者和仓库的协作者能触发这种命令。                           |
+| /reopen            | /reopen                               | 重新打开一个Issue。                                          | 作者和仓库的协作者能触发这种命令。                           |
+| /retest            | /retest                               | 重跑测试用例任务。                                           | 任何人都能在一个Pull Request上触发这种命令。                 |
+| /assign [[@]...]   | /assign /assign @openeuler-ci-bot     | 分配一个Issue给负责人。                                      | 任何人都能在一个Issue上触发这种命令， 但是目标负责人必须是这个组织的一个成员。 如果没有指定目标负责人，这表明这个Issue会分配给自己。 |
+| /unassign [[@]...] | /unassign /unassign @openeuler-ci-bot | 取消分配一个Issue给负责人。                                  | 任何人都能在一个Issue上触发这种命令， 但是目标负责人必须是这个组织的一个成员。 如果没有指定目标负责人，这表明这个Issue会取消分配给自己。 |
\ No newline at end of file
diff --git a/zh/sig-infrastructure/label.md b/zh/sig-infrastructure/label.md
new file mode 100644
index 0000000000000000000000000000000000000000..59d5b1c3f4c6d632434e8170a3a59029c1aff4f8
--- /dev/null
+++ b/zh/sig-infrastructure/label.md
@@ -0,0 +1,47 @@
+#  openEuler社区标签
+
+openEuler社区所有的项目都有很多标签。 这些标签给予了Issue和Pull Request某些特定的含义。 这些标签包括：
+
+### CLA
+
+- openeuler-cla/yes
+- openeuler-cla/no
+
+### Kind
+
+- kind/api-change
+- kind/bug
+- kind/cleanup
+- kind/design
+- kind/documentation
+- kind/failing-test
+- kind/feature
+- kind/enhancement
+
+### Priority
+
+- priority/high
+- priority/medium
+- priority/low
+
+### Sig
+
+- sig/kernel
+- sig/driver
+- sig/testing
+- sig/release
+- sig/doc
+- sig/api
+
+### CI
+
+- lgtm
+- approved
+
+### Others
+
+- duplicate
+- help-wanted
+- invalid
+- question
+- wontfix
\ No newline at end of file
diff --git a/zh/technical-committee/README.md b/zh/technical-committee/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..3bbea0e5523e7be1b96f431cc061a9d5bbdd52dd
--- /dev/null
+++ b/zh/technical-committee/README.md
@@ -0,0 +1,41 @@
+# 技术委员会
+
+openEuler技术委员会是openEuler理事会下社区的技术决策机构，负责社区技术决策和技术资源的协调。技术委员会的主要职责如下：
+
+- 对社区技术路线、接口定义、架构设计、构建发布等进行指导和决策
+- 协调跨项目合作，对社区跨项目技术问题进行决策
+- 制定项目孵化、开发流程，支撑社区技术生态健康发展
+- 批准新项目加入社区，并帮助社区开发者对新项目进行孵化
+- 根据社区发展蓝图，调整社区现有项目，对不符合社区规划的项目，进行删除或者归档
+- 接受用户委员会的反馈（需求和问题），明确技术实施计划，牵引社区资源将其落地至项目
+- 建立社区认证标准和平台，为社区认证（OS商业发行版认证、硬件兼容性认证等）提供技术支撑
+
+
+
+# 组织会议
+
+- 公开的会议时间：每周X 下午，北京时间XX点~XX点
+
+
+
+# 成员
+
+
+- 熊伟[[@myeuler](https://gitee.com/myeuler)]，华为
+- cynthia[[@cynthia_xh](https://gitee.com/cynthia_xh)]
+- Shinwell[[@Shinwell_Hu](https://gitee.com/Shinwell_Hu)]
+- 王勋[[@dream0819](https://gitee.com/dream0819)]
+- 郭寒军[[@hanjun-guo](https://gitee.com/hanjun-guo)]
+- 谢秀奇[[@xiexiuqi](https://gitee.com/xiexiuqi)]
+
+
+
+# 联系方式
+
+
+- [邮件列表](tc@openeuler.org)
+
+- [Open Community Issues/PRs]()
+
+  
+
diff --git a/zh/technical-committee/governance/README.md b/zh/technical-committee/governance/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..158bff6d72752893e89d9436bd83c60d2b24576b
--- /dev/null
+++ b/zh/technical-committee/governance/README.md
@@ -0,0 +1,82 @@
+# SIG/项目  Charter指南
+
+ 所有openEuler社区的SIG/项目都必须有一个章程（Charter）来明确SIG/项目的范围和治理规则。
+
++ 范围必须明确定义SIG/项目负责指导和维护的领域
++ 治理规则必须说明SIG/项目中的职责，以及拥有这些职责的角色和工作开展方式
+
+
+
+## 申请新SIG/项目章程的步骤 
+
+1.将[模板](template-SIG&project-governance.md)复制到community/proj*YOURPROJECT*/charter.md下的新文件中（[范例]()）
+
+2.为便于更好的理解模板里的内容，建议先阅读[建议书和要求](SIG&project-governance-requirement.md)
+
+3.填写您的SIG/项目申请模板
+
+4.请根据您申请模板中定义的SIG/项目，SIG/项目中的角色、以及SIG/项目的Repository信息更新[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)。SIG/项目的Repository请参考[openEuler的Repository说明](/../../Gitee-management/Gitee-management-guide.md)
+
+5.在openeuler.yaml中添加您的SIG/项目，以及这个SIG/项目拥有的子项目
+
+6.用修改好的charter.md和openeuler.yaml ，创建一个Pull Request，并在您的团队内对申请书内的SIG/项目范围和治理章程达成一致的意见
+
+7.请将SIG/项目章程（charter.md）发送给技术委员会审查（网址为tc@openEuler.org），并在正文中包含主题“*新SIG/项目提案*”和PR的链接
+
+8.技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改
+
+9.技术委员会将通过合并Pull Request的方式来批准您的申请
+
+
+
+## 更新现有SIG/项目章程的步骤
+
++ 对于重大变更或可能影响其他SIG/项目组的任何变更（例如范围变更），请填写PR申请，并将该申请发送给技术委员会，发送主题请标注成“*SIG/项目章程更新：*YOUR SIG/RPROJECT”
++ 对于影响范围小的变更，比如只影响本SIG/项目范围内的问题或领域，SIG/项目的Mainatiner可以自行协助进行变更
+
+
+
+##  SIG/项目章程批准流程
+
+引入新SIG/项目或对老SIG/项目的章程进行修改时，过程如下：
+
++ 从SIG/项目组中确定推动变更的负责人，最常见的就是SIG/项目的Mainatiner作为负责人
++ 变更所有者组织SIG/项目组成员一起制定变更内容，并与技术委员会讨论（为便于信息同步，可以在与指导委员会的沟通中键入SIG/项目组的邮件列表）。
++ 获取到技术委员会的批准意见后，提交PR并将邮件发送到tc@openeuler.org。对更改细节的讨论交流建议在申请PR之前在社区上进行。
++ 对于较大的变更，确认变更范围后请通知openEuler社区内受到影响的其他SIG/项目组，并将邮件发送到tc@openeuler.org，或者在社区门户上宣布。
+
+如果这一过程中有任何疑问，请联系技术委员会：tc@openEuler.org
+
+
+
+
+
+## SIG/项目申请社区发行提案步骤
+
+如果SIG/项目希望自己的交付件可以进入**社区发行范围**，请向技术委员会提出申请
+
+1.将[模板](template-release.md)复制到community/*YOUR SIG/PROJECT*/release.md
+
+2.按照模板要求填写SIG/项目毕业申请
+
+3.用修改好的release.md和openeuler.yaml ，创建一个Pull Request
+
+4.请将社区发行申请（release.md）发送给技术委员会审查（网址为tc@openeuler.org），并在正文中包含主题“SIG/项目社区发行提案”和PR的链接
+
+5.技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改
+
+6.技术委员会将通过合并Pull Request的方式来批准您的SIG/项目的社区发行申请
+
+**请注意，申请社区发行有三种类型**：
+
+- 第一种：进入发行光盘范围，
+- 第二种：进入`/extra`（不在光盘内的额外的软件包）目录
+- 第三种：进入`/experimental`（探索、实验性质的软件包）目录
+
+
+
+## 常见问题
+
+NULL
+
+
diff --git a/zh/technical-committee/governance/SIG&project-governance-requirements.md b/zh/technical-committee/governance/SIG&project-governance-requirements.md
new file mode 100644
index 0000000000000000000000000000000000000000..866fa53f881c33804be187733ad643e39cea22c7
--- /dev/null
+++ b/zh/technical-committee/governance/SIG&project-governance-requirements.md
@@ -0,0 +1,72 @@
+# SIG/项目治理要求
+
+
+
+## 目标
+
+
+本文简要描述了对SIG/项目的治理要求和建议。本文档使用[rfc2119](https://www.ietf.org/rfc/rfc2119.txt)表示关键字要求级别。
+
+
+
+## 检查清单
+
+
+以下是在定义openEuler SIG/项目治理规则时需要考虑的清单
+
+
+
+### 角色
+
++ *必须*枚举SIG/项目中的任何角色以及每一个角色的职责
++ *必须*定义更改角色的过程
+  + 何时以及如何向每一个角色添加新成员
+  + 现有成员何时以及如何从各个角色退休
++ *应该*定义角色成员的限制/要求
++ *可以*定义角色的目标人数
+
+
+
+### 组织管理
+
++ *必须*定义何时以及如何组织SIG/项目组成员之间的协作
+  + *应该*定义定期会议的安排和运作方式
+  + *应该*定义如何安排会议
+  + *可以*定义大家都比较闲暇的定期办公时间
++ *可以*定义新的社区成员为该SIG/项目做出贡献的过程，例如阅读贡献指南，参加SIG/项目组会议等
++ *必须*定义子项目的管理方式
+  + 何时以及如何创建新的子项目
+  + *必须*在子项目中定义角色（和成员资格） 
+
+
+
+### SIG/项目管理
+
++ *必须*定义里程碑/版本的设置方式，包括
+  + 如何建议和接受里程碑/发布的目标日期
+  + 里程碑的目标
+  + 发布版本的过程
++ *应该*定义如何管理事务和计划
+  + 如何确定优先级
+  + 如何安排优先级
+
+
+
+### 技术流程
+
+社区上没有代码的SIG/项目可以简化甚至忽略
+
++ *必须*定义如何在SIG/项目组内传递和制定技术决策
+  + 提案流程，在何处已经核实发布和讨论，何时以及如何做成决定
+  + 谁是提案的决策者
+  + 如何解决SIG/项目内的分歧（例如：讨论后投票）
+  + 分歧如何以及及时上升
+  + *应该*为提案流程定义期望和建议（例如：如果在两周内无法解决问题，则逐级上升）
+  + *应该*为通过正式流程的决策定义后期跟踪处理方式（例如：何时重新审视或撤销决策）
+
++ *必须*定义SIG/项目的技术资产的健康标准和发布标准
+  + 发布用于确定代码是否健康且可以发布的明确公开的标准
+  + *仅*在标准满足时，才能发布
+  + 确保技术资产处于可发布状态，以实现跨多个SIG/项目的里程碑/发布（如openEuler的LTS版本）
+  + *应该*为健康的标准定义明确的目标和指标（例如：在N提案修复破坏构建的bug）
+  + *应该*定义满足目标和指标的过程（例如：所有测试启动前的预验证等）
\ No newline at end of file
diff --git a/zh/technical-committee/governance/SIG&project-governance.md b/zh/technical-committee/governance/SIG&project-governance.md
new file mode 100644
index 0000000000000000000000000000000000000000..57bc28f0846861a38aaebbfaf7dcc771c5526fd4
--- /dev/null
+++ b/zh/technical-committee/governance/SIG&project-governance.md
@@ -0,0 +1,138 @@
+# SIG/项目角色和组织治理
+
+​        该Charter内容遵循openEuler宪章 [README](README.md)中描述的约定，本文会根据需要进行更新，以满足openEuler SIG/项目的需求。
+
+​        为了使SIG/项目的工作标准化，提高社区透明度，并将贡献者合理的到入到对应的SIG/项目组内，SIG/项目应该遵循以下准则：
+
+- 创建章程并根据[README](README.md)进行申请
+- 定期开会，建议每周至少30分钟
+- 持续保存最新的会议备忘录，并保存在对应的文件夹
+- 每季度至少在社区每周一次的会议中报告一次SIG/项目的活动，集成类SIG/项目可以调整成一年。
+- 根据需要参与发行计划会议、回顾会议和燃尽会议等
+- 确保在SIG/项目拥有的Gitee组织和存储库内开展相关工作，以支撑社区内的编码和测试，包括问题分类、PR审核、问题响应、错误修复等。
+- 采用[社区提供的邮件列表、IRC等主要方式](/../../communication)用于社区工作、沟通和合作,而不是私人邮件和会议。
+
+
+
+## 社区角色
+
+
+### 角色说明
+
+本节中的“成员”是指
+
+- 初始成员是在SIG/项目或子项目成立时定义的，是接受该SIG/项目或其子项目的一部分
+- 成员*应*保持活跃并积极响应自己的角色职责
+- 成员*必须*是社区成员，才有资格在SIG/项目组中担任领导角色
+- 休假超过1个月或更长时间的*成员*应该协调其他成员，以确保在休假期间为该角色配备足够的人员
+- 休假1-3个月的会议*可以*与其他会员合作，以确定临时的替补成员
+- 成员*应*删除未告知休假但超过一个月无法联系或超过一个月未履行其职责的任何其他成员。删除过程可以通过[超级多数](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote)投票来完成；如果没有足够的*活跃*成员来获得超级多数的投票，则可以通过Maintainer，Committer和子SIG/项目所有者之间的超级多数来投票罢免。
+- 如果对于成员有资格分歧，可以上升到Maintainer。如果对于SIG/项目的Maintainer的资格的分歧可以上升到技术委员会。
+- 成员*可以*决定随时退出并提议候选人，候选人应得到大多数SIG/项目组成员的支持。
+- 成员*可以*通过成员之间的[多数](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote)投票选择其他成员。
+
+
+
+### Maintainer：
+
+> 人数：1~3人
+> 工作职责：SIG/项目组的管理者，软件包的维护者。直接参与和技术委员会以及上游或周边的协调，但无汇报关系。初始由SIG/项目创建时指定，后继人选从Committer中选出。如SIG/项目组内暂无Committer或人数较少，Committer的职责可以由Maintainer兼任。
+>
+> - **确定SIG/项目的技术路线**：包括规划和决策SIG/项目技术方向、路标规划、架构演进。
+> - **制定SIG/项目的发布计划**：确定SIG/项目的关键需求和发布计划；参与社区的PM活动，并协调SIG/项目计划和社区版本的里程碑时间表匹配
+> - **参与社区协调活动**：作为SIG/项目的代表参与openEuler技术委员会或理事会组织的活动和特定会议等
+> - **召集SIG/项目组会议**：定期召集SIG/项目组会议，决策SIG/项目组内上升的争议
+> 
+> 角色配置：openeuler.yaml内的*developer*标签
+
+
+
+### Committer
+
+>可选角色
+>人数：2~8人
+>工作职责：特性设计方案审核和批准，代码审核及主干代码合入。Committer由Maintainer/Committer提名并由当前的Contributor全体投票表决产生。
+>
+>+  **评审PR**：对Contributor提交的PR完成评审，评审可以参考社区的[编程建议]()和[安全编程规范]()。
+>+  **分发处理问题**，请参考“[问题处理流程]()“。
+>+  **跟踪依赖性问题**：在开发分支中，其他SIG/项目组的软件包的更新可能会到导致破坏本SIG/项目内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。
+>+  **如有接口变更，通知可能会影响到的SIG/项目**：其他SIG/项目或团队会依赖本SIG/项目，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG/项目。具体请参考[接口变更通知流程]()。
+> +  **更新和维护软件包版本**：遵守社区的[软件包更新质量控制策略](/group-pm/)完成软件包的更新。
+> +  **和上游社区合作**，包括：
+>    +    将所有变更推送到上游社区
+>    +    参与上游社区邮件列表
+>    +    获取上游社区的bug跟踪器的账户，并跟踪上游社区的重要bug
+>   +    将严重的错误转发给上游社区以寻求帮助
+>          更多信息，请参考“[上游社区软件包管理建议]()”
+> +  **和测试团队合作**，包括：
+>    +  在提交软件包时，向质量检查人员提供如何调试/分类软件包的信息，以供问题的分类
+>    +  提供基本功能的测试用例，用于测试回归
+>    +  提交软件包更新时，提供有关更新中已经修复问题的测试用例，以供质量检查人员使用。 
+> 
+>角色配置：openeuler.yaml内的*developer*标签
+
+
+
+###  安全联络员
+
+>在committer中指定安全联络员
+>人数：1人
+>工作职责：
+>
+>+ 成为产品安全团队的对口SIG/项目组联络人，对本SIG/项目内的安全问题进行分类和处理。
+>+ 参与安全团队的安全问题
+>+ 维护SIG/项目组内的安全规范和要求
+
+
+
+## 组织管理
+
+
+### 会议管理
+
+- SIG/项目组应每一周召集一次会议，会议由Maintainer主持（除非委托给特定成员），固定议程可以由SIG/项目组内成员讨论确定
+- 深入讨论技术委员会指定给本SIG/项目组的——建议的技术和需求等，应由Maintainer组织（除非委托给特定成员）
+- 定期更新社区会议
+
+
+
+### SIG/项目组管理
+
++ 确定本SIG/项目组内的年度技术路线图和路标，并向社区PM发布
++ 提供SIG/项目组内版本的功能或需求清单
++ 根据要求参加社区内的版本会议，提供和执行SIG/项目计划
+
+
+
+### 子项目管理
+
+子项目可以由SIG/项目的Maintainer或Committer提案创建，子项目可以通过SIG/项目组内的Maintainer和Committer通过“懒惰的共识”（沉默即同意）评审接受，结果*应*得到大多数SIG/项目组成员的支持。
+
++ 提案创建者*必须*是子项目所有者
++ openeuler.yaml*必须*更新为包含子SIG/项目所有者的子项目信息和相关*OWNER*文件
++ 所有子项目的治理和流程原则上与SIG/项目相同，如有不同，*必须*在提案时说明。
++ 如子项目发布的执行方式和里程碑的设置与SIG/项目有差异，*必须*明确说明
++ 子项目的组织管理可以和SIG/项目合并，也可以单独运作。
+
+
+
+### 技术流程
+
+- 提出方案和决策请遵循决策流程
+- 保证SIG/项目组持续健康的测试
+      - 规范代码发布要求，如果可能可以合入到SIG/项目组的构建中检查
+          - 通过构建保证引入的问题会通过测试自动检测并发送告警
+          - SIG/项目组成员负责响应测试告警。如未能在24小时内修复，应该将破坏测试的PR回退
+          - 每次的SIG/项目组会议应检查测试结果，成员应处理发现的错误，并在下次会议上反馈进展、
+- 影响多个子项目的问题建议通过以下任意一种方式解决：
+     - 方式一：SIG/项目的Maintainer指定SIG/项目的技术Leader仲裁或决策
+     - 方式二：组织子项目的Maintainer联合会议
+
+
+
+### SIG/项目退出
+
+- 如果SIG/项目无法定期组织一定的人数或无法履行组织管理职责
+      - 6个月以上的，*应*启动退出
+          - 12个月或更长时间的，*必须*退出
+
diff --git a/zh/technical-committee/governance/template-SIG&project-charter.md b/zh/technical-committee/governance/template-SIG&project-charter.md
new file mode 100644
index 0000000000000000000000000000000000000000..1e73da0598a9da84d7926f5827591034fe504bc9
--- /dev/null
+++ b/zh/technical-committee/governance/template-SIG&project-charter.md
@@ -0,0 +1,79 @@
+# SIG/项目 Charter申请
+
+
+说明：本SIG/项目的Charter内容遵循openEuler章程 [README]()中描述的约定，使用[SIG&project-governance](SIG&project-gover)中概述的角色和组织管理。
+
+
+
+## 范围
+
+### 目标和价值
+
+用几句话简要描述新申请SIG或项目的范围。包括：
+
+ - 为什么需要在openEuler里创建一个这样的新SIG或项目（注意，二选一）
+
+ - 新SIG或项目的目标和范围
+
+ - 新SIG或项目将为谁服务
+
+ - 新SIG或项目需要得到openEuler内哪些SIG或项目的支撑
+
+   
+
+ ### 代码、二进制和服务
+
+ - 该SIG/项目内维护的成果件是那种形式，源码还是tar包或兼而有之？
+ - 属于此SIG/项目的范围是什么？包括不限于：子SIG/项目清单、维护的软件包清单
+ - 希望设置几个repository及其对应关系？
+
+
+
+ ### 跨领域和面向外部的流程
+
+ 由该SIG/项目定义和执行的，且跨领域和面向外部的流程和行动：
+
+ - 非内部流程清单
+ - 该SIG/项目拥有的面向整个openEulerSIG/项目的组织指导计划等
+
+
+
+### 不在本SIG/项目范围内的说明
+
+其他特殊说明
+
+
+
+
+
+## 角色和组织管理方式
+
+
+说明：本SIG/项目遵循[SIG&project-governance](SIG&project-gover)中定义的角色和组织管理方式，并对其进行如下修改。
+
+### Maintainer的其他职责
+
+- 其他选举方式和退出机制
+- 其他职责清单
+
+### Committer的其他职责
+
+- 其他选举方式和退出机制
+
+- 其他职责清单
+
+  
+
+### 与[SIG&project-governance](SIG&project-gover)的差异
+
+- 本SIG/项目的角色和治理方式与定义不同的地方
+
+- 如果SIG/项目没有Maintainer或Committer，请在此处指定
+
+  
+
+### 子项目创建说明
+
+- 子项目名称
+- 子SIG/项目范围说明
+
diff --git a/zh/technical-committee/governance/template-release.md b/zh/technical-committee/governance/template-release.md
new file mode 100644
index 0000000000000000000000000000000000000000..7d5dc13c81736c1be7d91afaa391e98af29b5178
--- /dev/null
+++ b/zh/technical-committee/governance/template-release.md
@@ -0,0 +1,38 @@
+# SIG/项目   交付件进入社区发行申请模板
+
+(还待补充或细化）
+
+## 软件包可以给openEuler带来的价值
+
+
+
+
+
+
+
+## 当前软件包的成功实践说明
+
+
+
+
+
+
+
+
+
+## 软件包在openEuler中的位置和依赖关系
+
+
+
+
+
+
+
+
+
+
+
+## 软件包申请进入的范围
+
+该SIG/项目申请进入openEuler发行的那个范围？（光盘范围、`extra`或者`experimental`）
+