doc: 添加部分社区治理文档（patch v1） (#5)

.vuepress/config.js

@@ -38,6 +38,10 @@ export default defineUserConfig({
                     'text': 'SIGs',
                     'link': '/sigs/',
                 },
+                {
+                    'text': "导师制",
+                    'link': '/mentorship/',
+                }
             ],
             sidebar: {
                 '/': 'heading',
@@ -47,9 +51,36 @@ export default defineUserConfig({
                         children: [
                             '/governance/',
                             '/governance/community-membership.md',
+                            '/governance/dev-group.md',
+                            '/governance/sig-wg-lifecycle.md',
+                            
+                        ]
+                    },
+                    {
+                        text:'SIG治理',
+                        children: [
+                            '/governance/sig-governance/',
+                            '/governance/sig-governance/sig-charter-guide.md',
+                        ]
+                    },
+                    {
+                        text:'WG治理',
+                        children: [
+                            '/governance/wg-governance/',
+                        ]
+                    }
+                ],
+                '/contributors/': [
+                    {
+                        text: '贡献者指南',
+                        children: [
+                            '/contributors/',
+                            '/contributors/guide.md',
+                            '/contributors/cheat-sheet.md',
+                            '/contributors/code_of_conduct.md',
                         ]
                     }
-                ]
+                ],
             }
         }
     ),

README.md

@@ -1,6 +1,6 @@
 
 <div align="center">
-  <img width="40%" src="/images/dragonos-full-logo.svg" alt="dragonos-logo"></br>
+  <img width="40%" src="./.vuepress/public/images/dragonos-full-logo.svg" alt="dragonos-logo"></br>
   <h2>DragonOS Community</h2>
 
 <a href="https://dragonos.org"><img alt="官网" src="https://img.shields.io/badge/%E5%AE%98%E7%BD%91-DragonOS.org-4c69e4?link=https%3A%2F%2Fbbs.dragonos.org.cn" ></a>
@@ -18,7 +18,7 @@
 
 如果您想了解更多关于项目结构以及DragonOS社区的内容，请转到[社区治理]以获取更多的信息！
 
-本文档的在线版本：[community.dragonos.org](community.dragonos.org)
+**本文档的在线版本：** [community.dragonos.org](https://community.dragonos.org)
 
 ## 交流讨论
 

contributors/README.md

@@ -1,3 +1,7 @@
-# 贡献者指南
+# 为DragonOS社区作出贡献
 
-TODO
+欢迎来到DragonOS社区的贡献文档。如果你愿意加入社区，我们将感到格外的兴奋！
+
+## 开始
+
+TODO

contributors/cheat-sheet.md

@@ -0,0 +1 @@
+# 贡献者备忘录

contributors/code_of_conduct.md

@@ -0,0 +1,77 @@
+# 贡献者行为准则
+
+作为 DragonOS 社区的贡献者、维护者和参与者，我们努力建设一个开放和受欢迎的社区，我们承诺尊重所有上报 Issue、发布功能需求、更新文档、提交 PR 或补丁、参加会议或活动以及其他社区和项目活动的贡献者和参与者。
+
+我们致力于让参与 DragonOS 社区的每个人都不受骚扰，无论其年龄、体型、种姓、残疾、族裔、经验水平、家庭状况、性别、性别认同和表达、婚姻状况、军人或退伍军人身份、国籍、个人外表、种族、宗教、性取向、社会经济地位、部落或任何其他多样性维度如何。
+
+## 适用范围
+
+本行为准则适用于：
+
+- DragonOS项目和社区空间
+- 其他空间（在DragonOS社区参与者的言论或行动涉及到DragonOS社区、DragonOS项目或者其他DragonOS社区参与者的情况下）
+
+
+## 我们的标准
+
+DragonOS 社区是一个开放、包容和互相尊重的社区。我们社区的每个成员都有受到他人尊重的权利。
+
+有助于营造积极社区环境的行为包括：
+
+- 对他人表现出同理心和善意
+- 尊重不同的观点、视角和经验
+- 给予并优雅地接受建设性反馈
+- 承担责任并向受我们错误影响的人道歉，并吸取教训
+- 关注点不只放在如何让我们自己受益，还要着眼于整个社区
+
+不可接受的行为包括：
+
+- 使用性化语言或图像，以及任何形式的性关注或挑逗
+- 恶意挑衅、侮辱或贬损评论，以及个人或政治攻击
+- 公开或私下骚扰
+- 未经明确许可发布他人的私人信息，如电子邮件地址、住址等
+- 在专业环境中可能被认为不适当的其他行为
+- 任何违反中国法律以及您所在国家/地区法律的行为。
+
+并且，我们严令禁止以下行为：
+
+- 故意妨碍PMC对违规行为的调查。
+- 对在合规调查中，提供了证据或信息的证人进行打击报复的行为。
+
+## 执行
+
+
+社区的维护者负责明确并执行我们可接受行为的标准，并将采取适当的公平纠正措施，以回应他们认为不适当、威胁性、冒犯性或有害的任何行为。
+
+PMC有权也有责任删除、编辑或拒绝不符合此行为准则的评论、提交、代码、wiki编辑、问题和其他贡献，并在适当的时候披露原因。
+
+任何滥用、骚扰或其他不可接受行为的实例都可以报告给PMC，联系方式为[pmc@dragonos.org](mailto:pmc@dragonos.org)。所有投诉都将得到及时和公平的审查和调查。
+所有社区领导者都有义务尊重任何事件报告者的隐私和安全。
+
+DragonOS社区目前的举报审查及处理决定由PMC负责。
+
+### 执行指南
+
+
+PMC将遵循这些社区影响指南，以确定违反此行为准则的任何行为的后果：
+
+1. 纠正
+社区影响：在社区中使用不适当的语言或其他被认为不专业或不欢迎的行为。
+后果：来自PMC的私下书面警告，明确违规的性质并解释为什么该行为是不适当的。可能会要求公开道歉。
+2. 警告
+社区影响：通过单一事件或一系列行为的违规。
+后果：警告并指出继续该行为的后果。在指定时间内，不得与相关人员互动，包括未经请求地与执行行为准则的人互动。这包括避免在社区空间以及外部渠道如社交媒体上的互动。违反这些条款可能导致临时或永久封禁。
+3. 临时封禁
+社区影响：严重违反社区标准，包括持续的不适当行为。
+后果：在指定时间内，禁止与社区进行任何互动或公共沟通。在此期间，不允许与相关人员公开或私下互动，包括未经请求地与执行行为准则的人互动。违反这些条款可能导致永久封禁。
+4. 永久封禁
+社区影响：表现出持续违反社区标准的模式，包括持续的不适当行为、对个人的骚扰或对个体群体的人身攻击或诋毁。
+后果：永久禁止在社区内进行任何形式的公开互动。
+
+## 参见
+
+本行为准则改编自 [Contributor Covenant](https://www.contributor-covenant.org) 2.1 版, 参见 [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]。
+
+社区处理方针灵感来源于 [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity)。
+
+有关本行为准则的常见问题的答案，参见 [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq)。

contributors/guide.md

@@ -0,0 +1,3 @@
+# 贡献者指南
+
+TODO

governance/README.md

@@ -1,3 +1,40 @@
-# Governance
+# 社区治理
 
-TODO
+## 原则
+
+DragonOS社区遵循以下原则：
+
+- 开源、开放：DragonOS社区坚持开源，并面向所有参与者开放。在公开场合进行协作。
+- 社区驱动：DragonOS社区坚持社区驱动开发。
+- 博采众长：根据技术的优势，以及项目的目标、范围、设计原则的一致性来接受各方的想法以及贡献。
+
+
+## 行为准则
+
+我们非常重视社区的良好环境，我们希望能够为DragonOS社区的贡献者和用户营造一个友好、积极的协作环境。
+为了让大家获得的良好的参与体验，各方均需遵守[DragonOS社区行为准则](/contributors/code_of_conduct.md)。
+
+## 社区组织架构
+
+DragonOS社区由社区管理委员会、开发群、项目发展群，以及由社区管理委员会设立的，执行特殊职能的委员会组成。其中，
+开发群和项目促进群面向公众开放，任何想要参与的人们，都能凭借自己的能力及付出，在其中找到自己的位置。社区管理委员会
+及其下属的各职能委员会，由于其工作的敏感性（如涉及到私密数据等），由DragonOS社区邀请的合作伙伴（组织或个人）参与，
+并不定期地向社区及公众披露信息。
+
+![社区组织架构](./images/gov_architecture.jpg)
+
+## 开发群
+
+开发群是DragonOS社区最重要的组织，由以下类型的子组组成：
+- SIG（特别兴趣小组）
+  - 子项目
+- 工作组
+- 项目管理委员会
+
+关于开发群的进一步介绍，请转到[开发群文档](./dev-group.md)
+
+## 委员会
+
+某些主题（例如安全或行为准则）需要谨慎处理。 SIG 是公开运作的自愿团体，任何人都可以加入，而委员会则没有开放的成员资格，并且并不总是公开运作。
+社区管理委员会可以根据需要组建特定职能的委员会，任期有限制或无限制。委员会的成员由社区管理委员会决定，但所有委员会成员必须是社区成员。
+与 SIG 一样，委员会也有章程和主席，并将定期向社区管理委员会报告，并根据章程向社区报告。

governance/annual-reports.md

@@ -0,0 +1,3 @@
+# 年度报告
+
+TODO

governance/community-membership.md

@@ -1 +1,171 @@
-# 社区成员资格
+# 社区成员资格
+
+| 名称 | 责任 | 要求 | 被定义在 |
+| --- | ---- | --- | ------- |
+| Maintainer | 为子项目或任务设定方向和优先级 | 对子项目表现出责任感和出色的技术判断力 | 对应的SIG的描述文件的子项目Maintainer列表 |
+| Approver | 审查并批准PR | 在该子项目上经验丰富的积极审阅者和贡献者 | 对应的SIG的描述文件的Approver列表 |
+| Reviewer | 审查并批准PR | 在子项目中有贡献，且在该子项目具有2次评审历史。 | 对应的SIG的描述文件的Reviewer列表 |
+| Member | 社区的积极贡献者 | 对项目作出积极贡献，且被2位Reviewer联合推荐 | DragonOS-Community的GitHub组织成员 |
+| Contributor | 参与社区 | 任何参与代码/非代码贡献的人 | 无 |
+
+## 新贡献者
+
+[新贡献者]应该受到现有成员的欢迎，帮助完成PR工作流程，并引导到相关的文档和沟通渠道。
+
+## 已经参与的社区成员
+
+社区的核心成员需要展现出对本文档原则的遵循，对项目组织、角色、政策、流程、惯例等的了解，以及技术或写作能力。特定角色的期望、责任和要求将在下面详细列出。
+
+
+## Member
+
+成员是社区中的 [持续活跃] 贡献者。他们可以有议题和PR分配给他们，通过GitHub团队参与SIGs，并且他们的PR会自动运行预提交测试。成员被期望继续作为社区的活跃贡献者。
+
+被定义在： DragonOS Community GitHub组织的成员
+
+### 要求
+- 在其GitHub账户上启用[双因素认证]
+- 为项目或社区做出**多次贡献**，足以展示对项目的**持续和长期承诺**。贡献应包括但不限于：
+  - 在GitHub上编写或审查PR，至少有一个**已合并**的PR。
+    **注意：** PR必须展示持续的积极承诺。一些例子包括：
+    - 一个经过数周协调共识的项目
+    - 数量较多的小型PR，时间跨度为数周到数月
+    - 数量较少的复杂或技术性PR，需要与社区成员合作解决一个问题（例如：回归、错误修复等）
+  - 在GitHub上提交或评论问题
+  - 为SIG、子项目或社区讨论做出贡献（例如：会议、论坛等）
+- follow [DragonOS Community的GitHub组织]
+- 在[DragonOS论坛]上拥有账户
+- 阅读过[贡献者指南]
+- 积极为1个或更多子项目做出贡献。
+- 由2位审查者推荐。**注意推荐的以下要求**：
+  - 推荐者必须与潜在成员有密切互动——例如：代码/设计/提案审查，协调问题等。
+  - 推荐者必须在[DragonOS Community的GitHub组织]内的至少一个SIG中是审查者或批准者或更高级别的技术职位。
+  - 推荐者尽量来自不同的单位（如果条件允许的话）
+- **在DragonOS-Community/teams_data仓库中[提出一个issue][membership request]**
+  - 确保您的推荐者在问题中被@提及
+  - 完成issue清单上的每一项
+  - 确保包含的贡献列表代表您在项目上的工作。
+- 让推荐您加入社区的审查者回复`+1`，以同意推荐。
+- 一旦您的推荐者回应，您的请求将由SIG管理人员负责审查。如果申请表中，有任何缺失的信息，您需要将其补充完整，否则无法通过审核。
+
+
+### 责任和权限
+
+- 对分配给他们的问题和Pull Request（PR）做出回应。
+- 对他们作为成员的SIG团队被提及时做出回应。
+- 对自己贡献的代码持续负责（除非明确转让所有权）。
+- 代码经过充分测试。
+- 测试一致通过。
+- 在代码被接受后，解决发现的问题或错误。
+- 他们可以被分配到问题和PR，并且人们可以通过 `r? @member的github用户名` 请求该成员进行评审。
+- 可以为他们的PR自动运行测试.
+- 成员可以使用 `@dragonosbot close` 等命令来关闭PR。
+
+注意： 经常贡献代码的成员应当要主动进行代码审查，并努力成为他们活跃的子项目的主要reviewer。
+
+## Reviewer
+
+审查者能够对子项目中的一部分代码进行质量和正确性的审查。他们对代码库和软件工程原则都有深入的了解。
+
+**被定义在：** 对应的SIG的描述文件的Reviewer列表
+
+Reviewer称号限定于代码库的一部分。
+
+**注意：** 接受代码贡献至少需要一个Approver以及分配的Reviewer。
+
+### 要求
+
+一个人如果要成为Reviewer，那么他应该：
+
+- 成为成员至少1个月
+- 至少作为5个PR的主要审查者，这些PR针对的是代码库
+- 审查或合并至少10个重要PR到代码库
+- 对代码库有深入了解
+- 由子项目Approver或更高级别的技术人员推荐
+  - 没有其他批准者的反对
+  - 通过更新SIG的README文件的PR来完成
+- 可以自我提名，也可以由本项目的一个Approver提名，或者由机器人提名
+
+### 责任与权限
+
+以下是某人作为Reviewer的责任与权限：
+
+- Code Reviewer状态可能是接受大型代码贡献的前提条件
+- 通过[code reviews]负责项目的质量控制
+  - 关注于代码质量和正确性，包括测试和代码结构
+  - 也可能审查更全面的问题，但这不是必需的
+- 预期将根据[社区期望]对审查请求做出响应
+- 分配与擅长的子项目相关的PR进行审查
+- 分配与擅长的子项目相关的测试bug
+- 被授予对DragonOS仓库的“读取访问”权限
+- 在PR和issue comment中可能会获得一个徽章
+
+## Approver
+
+Approver能够审查和批准代码贡献。代码审查专注于代码质量和正确性，而批准则专注于对贡献的整体接受，
+包括：向后/向前兼容性，遵守API和标志约定，细微的性能和正确性问题，与系统其他部分的交互等。
+
+**被定义在：** 对应的SIG的描述文件的Approver列表
+
+Approver状态限定于代码库的一部分。
+
+### 要求
+
+一个人如果要成为Approver，那么他应该：
+
+- 至少1个月作为代码库的审查者
+- 至少作为10个重要PR的主要审查者，这些PR针对的是代码库
+- 审查或合并至少20个PR到代码库
+- 由子项目Maintainer或SIG主席提名
+  - 没有其他子项目所有者的反对
+  - 通过更新SIG的README文件的PR来完成
+
+
+### 责任与权限
+
+以下适用于一个人作为Approver的责任与权限：
+
+- Approver状态可能是接受大型代码贡献的前提条件
+- 展示出良好的技术判断力
+- 通过[code reviews]负责项目的质量控制
+  - 关注于对贡献的整体接受，例如与可扩展性、其他特性的依赖性、向后/向前兼容性、API和标志定义等
+- 预期将根据[社区期望]对审查请求做出响应
+- 指导Contributor和Reviewer
+- 可以批准代码贡献以供合并
+
+
+## 子项目Maintainer
+
+**被定义在：** 对应的SIG的描述文件的子项目Maintainer列表
+
+详细责任及权限定义在SIG指令治理文档的 [子项目Maintainer] 部分。
+
+
+## 非活跃成员
+
+**成员是社区中的持续活跃贡献者。**
+
+维护一个健康社区的核心理念是鼓励积极参与。随着时间的推移，人们的关注点会发生变化，我们不期望他们永远积极地贡献。
+
+然而，成为DragonOS社区的GitHub组织 的一员，意味着拥有[一些权限]。这些能力不应该被那些不熟悉DragonOS项目当前情况的人使用。
+
+因此，那些长时间离开项目且没有任何活动的成员将被从 DragonOS社区的GitHub组织 中移除，并且在他们重新熟悉项目的当前状态后，将需要再次通过组织成员资格审查及晋升流程。
+
+
+### 如何衡量非活跃状态
+
+非活跃成员被定义为在12个月内对任何DragonOS组织内**没有**贡献的DragonOS组织成员。
+
+在长时间离开项目且没有活动之后，这些成员需要重新熟悉项目的当前状态，才能有效地做出贡献。
+
+
+[新贡献者]: /contributors/README.md
+[双因素认证]: https://help.github.com/articles/about-two-factor-authentication
+[贡献者指南]: /contributors/README.md
+[DragonOS论坛]: https://bbs.dragonos.org.cn
+[DragonOS Community的GitHub组织]: https://github.com/DragonOS-Community
+[membership request]: TODO
+[持续活跃]: #如何衡量非活跃状态
+[code reviews]: TODO
+[子项目Maintainer]: /governance/sig-governance/README.md#子项目Maintainer
+[一些权限]: #责任与权限

governance/dev-group.md

@@ -0,0 +1,67 @@
+# 开发群
+
+开发群是DragonOS社区最重要的组织，由以下类型的子组组成：
+- SIG（特别兴趣小组）
+  - 子项目
+- 工作组
+- 项目管理委员会
+
+## SIG（特别兴趣小组）
+这是DragonOS开发群最主要的组织，每个SIG由对该领域作出贡献，或感兴趣的成员组成。其共同目的是为了推进特定主题的项目。
+我们的目标是实现分布式决策结构和代码所有权，并提供用于完成工作、制定决策和加入新贡献者的集中论坛。项目的每个可识别的
+子部分（例如，github org、存储库、子目录、API、测试、issue、PR）都旨在由某个 SIG 拥有。
+
+SIG 涵盖的领域可能垂直集中于特定组件或功能，也可能是横向/跨领域的，跨越项目的许多/所有功能领域，或者支持项目本身。如：
+
+- 垂直领域：网络子系统、调度子系统、虚拟化
+- 横向：可扩展性、多架构支持
+- 项目：测试、发布、文档、项目管理、贡献者体验
+
+SIG 在任何特定时间都必须至少拥有一名、最好是两名 SIG 主席。 SIG 主席旨在成为组织者和促进者，负责 SIG 的运营以及与
+其他 SIG、项目管理委员会和更广泛社区的沟通和协调。
+
+每个 SIG 必须有一份章程，规定其范围（主题、子系统、代码存储库和目录）、职责、权限范围、如何选择/授予权限/领导力的成员和角色、
+如何做出决策以及如何解决冲突。有关如何管理特许权的详细信息，请参阅[SIG章程指南]。在跨 SIG 流程
+（例如，项目集成测试、发布上线等流程）和资产（例如，存储库）施加的一些广泛的指导方针和约束范围内，SIG 应该相对自由地定制或更改其运作方式。
+
+SIG 存在的主要原因是作为协作论坛。SIG 中的许多工作都应该保留在该 SIG 的本地范围内。然而，SIG 必须公开沟通，确保其他 SIG 和
+社区成员可以找到会议、讨论、设计和决策的记录，并定期向社区传达 SIG 工作的高级摘要。有关当前 SIG 操作机制的更多详细信息，
+例如论坛板块、会议时间等，请参阅[SIG治理文档]
+
+## 子项目
+SIG 内的具体工作分为多个子项目。 DragonOS 代码和文档的每个部分都必须属于某个子项目。一些 SIG 可能只有一个子项目，但许多 SIG 拥有多个重要的子项目，
+这些子项目具有不同的（尽管有时重叠）一组贡献者和Maintainer，他们充当子项目的技术领导者：负责愿景、方向和总体设计等。
+
+一些 SIG 的子项目示例：
+
+- 文件系统SIG：虚拟文件系统、FAT文件系统等
+
+每个 SIG 的子项目都记录在其目录下的**subprojects.md**中。
+
+## WG（工作组）
+工作组用来促进短暂的或者是跨越多个 SIG 的主题的讨论/工作。
+
+工作组主要用于促进DragonOS范围内但跨 SIG的讨论主题。如果社区中的一群人想要聚在一起讨论某个主题，他们可以在不成立工作组的情况下这样做。
+
+有关组建和解散工作组的更多详细信息，请参阅[工作组治理]。
+工作组记录在[工作组文档]中。
+
+## 项目管理委员会（PMC）
+
+项目管理委员会负责管理管理各个SIG以及WG，制定及管理项目发展方向。
+- PMC负责审阅、批准、驳回SIG和WG的成立、变更、撤销等事项。
+- PMC负责决定项目的发展方向。
+- 所有技术责任均应委托给 SIG（即PMC本身不应保留技术责任）
+- PMC负责与项目促进群的各团队进行沟通协调。
+- 制定和完善定义新社区团体的政策(3)，并为这些团体制定透明度和问责政策。
+- 定义并维护SIG和WG的治理结构和政策。
+- PMC负责与特殊职能的委员会进行事项对接，但涉及的事项应当同时抄送给社区管理委员会。若涉及重大/敏感事项，应获得CMC的同意。
+- 应当每个月以书面形式，向社区管理委员会(CMC)汇报其工作进展.
+- 对于项目的重大事件及变更，以及财务、法务事件，均需在48小时内告知社区管理委员会。
+- PMC成员的任免，在经过PMC的投票机制后，应得到CMC的半数以上成员的同意。
+
+
+[SIG治理文档]: ./sig-governance/README.md
+[SIG章程指南]: ./sig-governance/sig-charter-guide.md
+[工作组文档]: /wgs/README.md
+[工作组治理]: ./wg-governance/README.md

governance/sig-governance/README.md

@@ -0,0 +1,95 @@
+# SIG治理
+
+对SIG进行标准化治理的目标是，让每个SIG都能保持透明度，并且能够让贡献者找到适合的SIG。因此，所有的SIG都应遵循以下的准则：
+
+- 经过SIG章程指南批准成立。
+- 定期会议：每个月至少30分钟。（6月和12月除外）
+- 保留会议记录，并提交到Community仓库内。
+- 录制会议，并在DragonOS开源社区的bilibli官方账号上公开播放
+- 记录活动并完成年度报告
+- 确保相关工作在项目拥有的 GitHub 组织和存储库中进行，代码和测试由 SIG 明确拥有和支持，包括问题分类、PR 审查、测试失败响应、错误修复等。
+- 使用[提供的论坛]作为工作、沟通和协作的主要方式，而不是私人电子邮件和会议。
+- 如果SIG的贡献指南与DragonOS社区的一般贡献指南有出入，请确保在 DragonOS-Community/community存储库中的 SIGs 文件夹中定义贡献说明 (CONTRIBUTING.md)。
+- 帮助和赞助 SIG 有兴趣投资的工作组
+
+## 角色
+
+### 关于角色的说明
+
+在本节中，“负责人”指的是担任主席、技术负责人或子项目负责人角色之一的社区成员。负责人可能担任多个角色，而且常常是这样。
+任何 DragonOS社区小组都没有单一的负责人。负责人对小组的一部分有特定的决策权，因此也有额外的责任。每个角色的具体说明如下。
+
+初始角色在 SIG 或子项目成立时作为接受该 SIG 或子项目的一部分而定义。
+
+### 负责人
+
+#### 活动期望
+- 负责人应保持在其角色中的活跃和响应性。
+- 如果负责人计划休假1个月或更长时间，应与其他负责人协调，以确保休假期间角色得到充分的人员支持。
+- 休假1-3个月的负责人可以与其他负责人合作，确定一名临时替代者。
+- 负责人应移除任何未通知休假且一个月以上无法联系或一个月以上未履行其文档职责的其他负责人。
+  - 移除可以通过活跃负责人的**绝对多数**投票来实现。
+  - 如果没有足够的*活跃*负责人，那么剩余的活跃主席、技术负责人和子项目负责人之间的**绝对多数**投票可以决定移除负责人。
+
+
+#### 要求
+- 负责人必须是至少是[我们贡献者列表上定义的"成员"]，才有资格在 SIG 中担任领导角色。
+- SIG 可能会根据角色的不同，要求对应的负责人具有相关领域的知识。这些要求应当以文本形式记录下来。
+- 对人员管理感兴趣，并且有相应的管理技能。
+
+#### 向上反馈
+
+- 负责人成员资格的争议可以向上反馈到 SIG 主席。SIG 主席成员资格的争议可以向上反馈到项目管理委员会(PMC)。
+
+#### 负责人的入职和离职
+- 负责人可以随时决定卸任并提出替代者。在其他负责人中使用懒人共识，以多数票作为后备来接受提案。候选人应得到 SIG 贡献者或子项目贡献者（如适用）的多数支持。
+- 负责人可以通过负责人之间的**绝对多数**投票选择额外的负责人。这应得到 SIG 贡献者或子项目贡献者（如适用）的多数支持。
+
+#### 所有负责人
+- 应该维护他们的 SIG 或子项目的健康
+- 应该至少对一个子项目或整个 SIG 显示持续的贡献。
+- 应该在 SIG 和/或至少一个子项目中持有一些文档化的角色或责任（例如审阅者、批准者等）
+- 可以为子项目构建新功能
+- 可以参与他们担任角色的子项目的决策
+
+#### 主席
+- 数量：2人或以上
+- 成员资格在 **SIG的README文件** 中记录
+- 应定义如何管理优先级和承诺。可以根据需要委派给其他负责人。
+- 应推动宪章变更（包括创建）以获得社区的认同，但可以将内容创建委派给 SIG 贡献者。
+- 必须与子项目负责人共同识别、跟踪和维护 SIG 在当前版本的DragonOS中的变更（比如改进了什么功能，修了什么bug）的列表。但可以委派给其他贡献者来履行这些职责。
+- 可以将 SIG 路线图的创建委派给其他负责人。
+- 必须组织主要小组会议并确保 **SIG的README文件** 保持最新，包括子项目及其会议信息，但应将子项目会议的需要委派给子项目负责人。
+- 应促进会议，但可以委派给其他负责人或未来的主席/培训中的主席。
+- 如果贡献者体验或入职知识与通用 [贡献者指南] 中的不同，必须在适当的 SIG 文件夹中确保有一个维护的 CONTRIBUTING.md 文档。可以委派给贡献者来创建或更新。
+- 必须确保会议被记录并可供查看。
+- 必须协调与其他社区小组如 SIGs 和项目管理委员会的沟通，并成为连接者，但可以在适当的情况下将实际沟通和内容创建委派给其他贡献者。
+- 必须创建SIG的年度 [年度报告]，但应从其他 SIG 参与者那里获得帮助以便进行策划。
+
+#### 子项目Maintainer
+
+子项目Maintainer是 DragonOS 社区中子项目的技术权威。他们必须展现出对子项目健康的良好判断力和责任感。
+- 数量：2人或以上
+- 成员资格在 **SIG的README文件** 中记录，并限定在子项目范围内
+- 必须为他们的子项目设定技术方向，直接或通过委派做出或批准设计决策
+- 必须指导和培养批准者、审阅者和子项目的贡献者。
+- 必须维护组件，审查，指导并批准增强子项目所拥有领域的提案
+- 必须积极参与问题分类和审查 PR
+- 应该作为子项目中技术讨论和决策的升级点
+- 应该设定里程碑优先级或委派此责任给其他负责人
+- 应该确保有一个健康的讨论和决策流程。
+- 可以做出决策以解决冲突
+
+
+## SIG 的撤销
+
+如果 SIG 无法达到SIG治理规范规定的人数或无法履行其组织管理职责：
+
+- 在 3 个月或更长时间后，它 **应该** 被撤销
+- 在 6 个月或更长时间后，它 **必须** 被撤销
+
+
+[我们贡献者列表上定义的"成员"]: /governance/community-membership.md
+[提供的论坛]: /communication/README.md
+[贡献者指南]: /contributors/README.md
+[年度报告]: /governance/annual-reports.md

governance/sig-governance/sig-charter-guide.md

@@ -0,0 +1,39 @@
+# SIG章程指南
+
+所有 DragonOS SIG 都必须定义一份章程，定义 SIG 的范围和治理。
+
+- 范围必须定义 SIG 负责指导和维护的领域。
+- 治理必须概述 SIG 内的职责以及承担这些职责的角色。
+
+
+## 创建 SIG 章程的步骤
+
+1. 将模板复制到`community/sigs/sig-YOURSIG/charter.md`下的新文件中（`sig-example`是一个示例）
+2. 阅读建议和要求，以便了解模板的背景信息
+3. 填写您的 SIG 模板
+4. 将您的信息更新到模版中
+5. 将SIG信息添加到[teams_data](https://github.com/DragonOS-Community/teams_data)仓库中（在teams_data仓库发起一个PR，并把它与community仓库的PR进行关联）
+6. 在community仓库创建拉取请求。在您目前所属的 SIG 内进行沟通并根据需要获取反馈。
+7. 将 SIG 章程发送至[pmc@dragonos.org]供审核。在正文中包含主题“SIG 章程提案：YOURSIG”和 PR 链接。
+8. 通常希望在发送草稿后一周内得到反馈。如果遇到假期，则预计需要更长的时间。您需要根据审查建议，进行任何必要的更改。
+9. 一旦被接受，项目管理委员会（PMC）将通过合并来批准 PR。
+
+
+## 更新现有 SIG 章程的步骤
+
+- 对于重大变更或可能影响其他 SIG 的任何变更（例如范围），请创建 PR 并将其发送给项目管理委员会（PMC）进行审查，主题为：“SIG 章程更新：YOURSIG”
+- 对于仅影响 SIG 范围内的问题或领域的细微更新，SIG 主席应推动变更。
+
+## SIG 章程批准流程
+在引入 SIG 章程或修改章程时，应使用以下流程。作为其中的一部分，我们将定义OARP流程的角色（所有者、批准者、审阅者、参与者）
+
+- 从 SIG 中确定一小组负责人来推动变革。最典型的是 SIG 主席。
+- 与相关 SIG 的其他成员（审阅者）合作来制定变更。确保SIG的成员能知晓与项目管理委员会的沟通情况。
+- 与项目管理委员会（批准者）合作以获得批准。只需提交 PR 并将邮件发送至 [pmc@dragonos.org] 即可。如果需要进行更实质性的更改，建议在起草 PR 之前，在社区内公开讨论，以便让其他人知晓。
+  - 项目管理委员会将努力确保章程中规定的 SIG 范围合理（并且在DragonOS范围内）并且流程公平。
+- 对于大型变更，为了让变更范围变得清晰，请向 DragonOS社区的其他成员（参与者）发出通知，您可以在DragonOS社区论坛上发出信息。
+
+
+如果对此过程有任何疑问，请通过[pmc@dragonos.org]联系项目管理委员会。
+
+[pmc@dragonos.org]: mailto:pmc@dragonos.org

governance/sig-wg-lifecycle.md

@@ -0,0 +1,3 @@
+# SIG和WG的生命周期
+
+TODO

governance/wg-governance/README.md

@@ -0,0 +1,90 @@
+# 工作组治理
+
+## 过程概述和动机
+
+工作组为不同群体提供了一个正式的途径，以便围绕共同问题进行协作，平衡各方的需求，并在完成后解散。
+由于它们代表多个群体的利益，因此它们是建立共识的工具。如果作为工作组内协作的一部分开发了代码，
+那么该代码将存放在一个适当的仓库中。最终，将此代码合并到仓库中将由提交代码到该仓库的标准政策
+（例如，在 SIGs 拥有的一个或多个子项目中开发）管理。
+
+因为工作组是DragonOS项目的官方组成部分，所以其成立和解散受到项目管理委员会(PMC)的监督。
+
+创建和/或已撤销的工作组清单可以在 [SIG和WG的生命周期] 文档中找到。
+
+
+## 此流程的目标
+
+- 为那些希望成立并最终解散新的工作组的人提供一个易于导航的过程
+- 在工作组有意义的地方提供简单指导和区分，以及无意义的地方
+- 清晰理解工作组不授予任何权力
+- 确保所有未来的工作组符合此过程
+
+## 不是此流程的目标
+
+- 记录其他治理机构，如子项目或 SIGs
+- 更改现有工作组/ SIGs /子项目的状态
+
+## 工作组与 SIGs 的关系
+
+DragonOS项目拥有的资产（例如代码、文档、博客、流程等）由SIG拥有和管理。例外的是，工作组可能拥有的特定资产，如下所述。
+
+工作组为治理和沟通渠道提供结构，因此可能拥有以下类型的资产：
+
+- 日历事件
+- 论坛版块
+- 微信/QQ群组
+
+工作组与 SIGs 的不同之处在于，它们旨在：
+- 促进 SIGs 之间的协作
+- 通过一个具有最小管理开销的团体来探索问题及其对应的解决方案
+
+工作组通常会有利益相关方，其参与是在一个或多个 SIGs 的背景下。这些 SIGs 应作为工作组的利益相关方记录在 这个工作组的README文件中（见创建过程）。
+
+### 信息同步
+
+工作组组织者需要向各自的代表的 SIG 的主席同步相关的信息。组织者负责向项目管理委员会提交[年度报告]。
+
+## 它是一个工作组吗？是的，如果...
+- 它不拥有任何代码
+- 它有一个通过特定可交付成果或多个可交付成果衡量的明确目标
+- 它的性质是临时的，并在达到其声明目标后解散
+
+## 创建过程描述
+
+工作组成立的过程比 SIG 成立的过程控制得更松，因为它们：
+
+- 不拥有代码
+- 有明确的进入和退出标准
+- 没有任何组织权力，只有影响力
+
+因此，工作组成立的过程从组织者问自己一些重要问题开始，这些问题最终应反映在 community仓库 的一个PR中：
+
+1. 这个团体试图解决的确切问题是什么？
+2. 这个团体将交付什么工件，以及交付给谁？
+3. 该团体如何知道问题解决过程已完成，是时候解散工作组了？
+4. 所有参与解决这个问题的利益相关 SIG 是哪些？
+5. 会议机制是什么（频率、持续时间、角色）？
+6. 工作组的目标是否代表整个项目的需求，还是仅聚焦于一小部分贡献者或公司的利益？
+7. 谁将主持该团体，并确保它继续满足这些要求？
+8. 工作组中是否很好地代表了多样性？
+
+请注意，所有工作组组织者和其他领导角色的持有者必须是 [社区成员]。
+
+回答上述问题后，完成 [SIG和WG的生命周期] 文档中的其余清单。
+PR合并后，工作组正式成立，直到它完成声明的目标，或自愿解散（例如，由于新事实、成员流失、方向改变等）。工作组应努力向利益相关 SIG 定期报告，以确保使命仍与当前状态保持一致。
+工作组的可交付成果（文档、图表）应存放在为工作组创建的目录中。
+
+## 解散过程描述
+
+如果以下任一情况为真，工作组将被解散：
+
+- 不再有一个主席
+  - （有 4 周的宽限期）
+- 工作组成立时，提交到community仓库的任何公开沟通渠道都没有使用
+  - （有 3 个月的宽限期）
+  - bbs上的板块
+  - 会议链接
+
+[年度报告]: /governance/annual-reports.md
+[SIG和WG的生命周期]: /governance/sig-wg-lifecycle.md
+[社区成员]: governance/community-membership.md

mentorship/README.md

@@ -0,0 +1,3 @@
+# 导师制
+
+TODO

wgs/README.md

@@ -0,0 +1,5 @@
+# 工作组
+
+## 所有工作组
+
+TODO