doc: 添加导师制文档（还没创建mentorship仓库，还没添加导师申请问卷） (#19)

* doc: 添加导师制文档（还没创建mentorship仓库，还没添加导师申请问卷）

* doc: 添加对github工作流和PR流程的描述

.vuepress/config.js

@@ -88,7 +88,9 @@ export default defineUserConfig({
                         text: '贡献者指南',
                         children: [
                             '/contributors/',
-                            '/contributors/guide.md',
+                            '/contributors/code-style.md',
+                            '/contributors/github-workflow.md',
+                            '/contributors/pull-requests.md',
                             '/contributors/cheat-sheet.md',
                             '/contributors/code_of_conduct.md',
                             '/contributors/expectation.md',
@@ -128,6 +130,24 @@ export default defineUserConfig({
                         ]
                     }
                 ],
+                '/mentorship/': [
+                    {
+                        text: '导师制',
+                        children: [
+                            '/mentorship/',
+                            '/mentorship/mentee-guide.md',
+                            '/mentorship/mentor-guide.md',
+                        ]
+                    },
+                    {
+                        text: '指导计划',
+                        children: [
+                            '/mentorship/programs/educational-learning-courses.md',
+                            '/mentorship/programs/project-based-mentorship.md',
+                            '/mentorship/programs/ospp.md',
+                        ]
+                    }
+                ],
 
             }
         }

communication/README.md

@@ -64,7 +64,14 @@ Issue是最直接最简单的沟通方式，issue里面包含了正式的提问
 
 ### 微信公众号
 
-在微信搜索“DragonOS”即可
+在微信搜索“DragonOS”即可.
+
+## 什么样的消息才是合适的？
+
+在社区沟通平台上的所有信息均受[DragonOS社区行为准则]的约束。您在社区沟通平台上发送的信息，将会被社区贡献者和DragonOS的用户或者是其他人所看到，
+因此，商业信息将收到严格的审核。请注意，允许商业内容，但是，未经审核的商业内容一般是不允许的。**关于商业内容的审核，请通过邮件，与PMC(项目管理委员会)进行沟通。**
+
+项目管理委员会联系方式：[pmc@dragonos.org]
 
 
 [社区成员资格]: /governance/community-membership.md
@@ -73,4 +80,4 @@ Issue是最直接最简单的沟通方式，issue里面包含了正式的提问
 [WG(工作组)列表]: /wgs/wg-list.md
 [DragonOS社区论坛]: https://bbs.dragonos.org.cn
 [DragonOS Community Conference]: /communication/dragonos-community-conference.md
-
+[pmc@dragonos.org]: mailto:pmc@dragonos.org

contributors/code-style.md

@@ -0,0 +1,94 @@
+# 代码风格指南
+
+## Rust语言代码风格
+
+  这篇文档将会介绍DragonOS中的Rust语言代码风格。随着开发的进行，这些风格可能会发生变化，但是我们会尽量保持风格的一致性。
+
+### 1. 命名
+
+  这部分基于Rust语言圣经中的[命名规范](https://course.rs/practice/naming.html)进行修改，本文未提及的部分，请参考Rust语言圣经中的[命名规范](https://course.rs/practice/naming.html)。
+
+### 2. 格式
+
+#### 2.1 缩进
+
+  请在提交代码之前，使用`cargo fmt`命令对代码进行格式化。
+
+#### 2.2 函数返回值
+
+  尽管Rust可以返回函数的最后一行的语句的值，但是，这种方式会使代码的可读性变差。因此，我们推荐您在函数的最后一行使用`return`语句，而不是直接返回值。
+
+```rust
+// 不推荐
+fn foo() -> i32 {
+    1 + 2
+}
+
+// 推荐
+fn foo() -> i32 {
+    return 1 + 2;
+}
+```
+#### 2.3 错误处理
+
+  DragonOS采用返回Posix错误码作为**模块间错误处理**的方式。为了确保在模块之间，错误处理代码的一致性，我们推荐在发生错误的时候，返回`SystemError`类型，该类型表示posix错误码。这样做的优点尤其体现在跨模块调用函数时，可以直接返回通用的错误码，从而降低错误处理代码的耦合度。
+
+```rust
+// 函数跨越模块边界时（由其他模块调用当前函数），不推荐
+fn foo() -> Result<(), CustomErr> {
+    if 1 + 2 == 3 {
+        return Ok(());
+    } else {
+        return Err(CustomErr::error);
+    }
+}
+
+// 函数跨越模块边界时（由其他模块调用当前函数），推荐
+fn foo() -> Result<(), SystemError> {
+    if 1 + 2 == 3 {
+        return Ok(());
+    } else {
+        return Err(SystemError::EINVAL);
+    }
+}
+```
+
+&emsp;&emsp;在**模块内部**，您既可以采用返回自定义错误enum的方式，也可以采用返回`SystemError`的方式。但是，我们推荐您在模块内部，采用返回自定义错误enum的方式，这样可以使错误处理代码更加清晰。
+
+&emsp;&emsp;**TODO**: 将原有的使用i32作为错误码的代码，改为使用`SystemError`。
+
+### 3. 注释
+
+&emsp;&emsp;DragonOS的注释风格与Rust官方的保持一致。同时，我们推荐您在代码中加入尽可能多的有效注释，以便于其他人理解您的代码。并且，变量、函数等声明，遵守第一节中提到的命名规范，使其能够“自注释”。
+
+#### 3.1 函数注释
+
+&emsp;&emsp;函数注释应该包含以下内容：
+
+- 函数的功能
+- 函数的参数
+- 函数的返回值
+- 函数的错误处理
+- 函数的副作用或者其他的需要说明的内容
+
+&emsp;&emsp;函数注释的格式如下：
+
+```rust
+/// # 函数的功能
+/// 
+/// 函数的详细描述
+/// 
+/// ## 参数
+/// 
+/// - 参数1: 参数1的说明
+/// - 参数2: 参数2的说明
+/// - ...
+/// 
+/// ## 返回值
+/// - Ok(返回值类型): 返回值的说明
+/// - Err(错误值类型): 错误的说明
+/// 
+/// ## Safety
+/// 
+/// 函数的安全性说明
+```

contributors/github-workflow.md

@@ -0,0 +1,107 @@
+# GitHub 工作流程
+
+本文旨在向您介绍DragonOS社区的GitHub工作流程。包括一些用于帮助你维持本地环境与社区上游仓库同步的建议，还有一些git提交规范等等。
+
+**本文以DragonOS主仓库为例，社区的其他仓库亦适用此工作流程**
+
+[[toc]]
+
+## 1. 在GitHub上创建一个Fork
+
+1. 打开 https://github.com/DragonOS-Community/DragonOS
+2. 点击页面右上角的`Fork`按钮，在你自己的账户下创建一个fork
+
+## 2. 克隆主仓库到你的电脑
+
+把**主仓库**克隆到你的电脑（注意不是你账户下Fork后的仓库）
+
+```shell
+
+git clone https://github.com/DragonOS-Community/DragonOS
+# 或者是 git clone git@github.com:DragonOS-Community/DragonOS
+
+cd DragonOS
+
+```
+
+接着，添加你fork的仓库，假设你的名字叫`zhangsan`，那么就执行以下命令：
+
+*注意替换url为你账号下的仓库的链接*
+
+```shell
+
+git remote add zhangsan https://github.com/zhangsan/DragonOS
+# 或者是 git remote add zhangsan git@github.com:zhangsan/DragonOS
+
+# 设置永远不推送到远程的master分支
+git remote set-url --push origin no_push
+
+# 确认你设置的远程已经生效
+git remote -v
+
+```
+
+## 3. 创建工作分支
+
+**请记住：** 永远不要在你本地的master分支上进行提交。请保持master分支与社区仓库的master一致。
+
+在开发之前，需要创建新的分支。每个PR都要使用一个新的、干净的分支。
+
+首先，请切换到本地的master分支（或者main分支），然后让它与远程同步。
+
+```shell
+git fetch origin
+gir checkout master
+```
+
+创建你的工作分支：
+
+```shell
+git checkout -b patch-my-feature
+```
+
+请注意，分支名字应当能简短的说明这个pr是干啥的。
+
+接着，你就可以开始开发了！
+
+## 4. 使你的分支与远程最新的代码保持同步
+
+在开发过程中，您需要周期性的从社区主仓库合并代码到你本地的工作分支。如果您长期不同步主仓库代码，那么就会产生很多的冲突，甚至导致您的更改难以合并到主仓库。
+
+在执行以下命令之前，请您先切换到您的开发分支，然后执行以下命令：
+
+```shell
+git fetch origin
+git rebase origin/master
+```
+
+请注意，不要使用`git pull`来合并主仓库代码到你的开发分支。请务必使用以上命令。因为，`git pull` 
+会创建merge commits，这会让提交历史变得混乱，使得您的PR的commit历史记录就变得难以理解了。
+
+## 5. 提交你的更改
+
+一般来说，直接提交就行。
+
+```shell
+git commit
+```
+
+你可能会经常把你的更改进行commit，以便能够回退更改.
+
+## 6. 推送到GitHub
+
+当你的PR已经完成，能够准备进行审查的时候，请你把工作分支推送到你在GitHub上的仓库。
+
+以上面的远程`zhangsan`为例，命令如下：
+
+```shell
+git push zhangsan patch-my-feature
+```
+
+## 7. 创建新的Pull Request
+
+1. 打开你在GitHub上Fork的仓库 `https://github.com/<username>/DragonOS`
+2. 点击右上角的`Compare & Pull Request`按钮，然后选择分支`patch-my-feature`，目标为社区主仓库的`master`分支（或`main`分支）。
+3. 关于Pull Request的进一步要求，请查看[Pull Request流程介绍]
+
+[Pull Request流程介绍]: /contributors/pull-requests.md

contributors/guide.md

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

contributors/pull-requests.md

@@ -0,0 +1,331 @@
+# Pull Requests指南
+
+本文介绍了向 [DragonOS项目](https://github.com/DragonOS-Community/DragonOS) 及其子项目提交Pull Requests的流程。
+
+*如果您尚不熟悉我们的GitHub工作流程，请先阅读[GitHub工作流程]*
+
+
+[[toc]]
+
+
+## 在提交PR之前
+
+本指南适用于已经在本地完成开发的人。如果您想知道如何设置开发环境，以及如何为DragonOS社区作出贡献，请转到[贡献者指南]
+
+如果您是第一次为DragonOS社区作出贡献，请先从’[为DragonOS社区作出贡献]’这篇文章开始阅读！
+
+
+**确保您的拉取请求符合我们的最佳实践。这些实践包括遵循项目规范、提交小的拉取请求以及充分注释。**
+
+
+### 运行本地的测试
+
+当你在提交PR之前，请运行以下命令进行本地测试：
+
+* 格式化代码（`make fmt`或者`cargo fmt`）
+* 运行静态测试 （对于DragonOS仓库而言，是`cd kernel && make test`）
+
+## PR的流程
+
+- [创建一个PR](https://help.github.com/articles/about-pull-requests/)
+- 签署CLA（暂时还不需要）
+- 通过自动化测试
+- 获得来自reviewer，以及代码拥有者的“Approve”
+
+
+## 某个Feature或者PR是必要的吗？
+
+有时候我们想到了一些点子，或者发现了一些“BUG”（请注意是有双引号的）。在开始开发之前，最好的方式是先与社区的成员们讨论它！
+
+也许这些feature是不必要的，或者不是bug。在讨论后，你将能获得更好的解决方案！
+
+您可以在[社区沟通渠道]上发帖，与大家交流！
+
+## 保持简洁、无需、最小可行性产品等原则
+
+有时我们需要提醒彼此软件设计的核心原则——“保持简洁”、“你不需要它（YAGNI）”、“最小可行性产品（MVP）”等。 
+
+往项目里面添加“也许我们以后需要（但现在用不上，也难以充分验证）”的功能，是与我们的开发原则相违背的。
+
+请你添加你现在需要的功能，并且为将来可能需要的功能，留出可扩展的空间——但是请不要现在实现他们！
+
+## 小即是美：小的提交，小的请求
+
+小的提交和小的请求审查得更快，而且比大的更可能正确。
+
+*注意力是一种稀缺资源。*
+
+如果你的请求需要60分钟来审查，审查者在最后30分钟的注意力可能不如最初的30分钟敏锐。
+
+如果需要一个大的连续时间段来进行审查，它可能根本就不会被审查！
+
+### 拆分commit
+
+将你的请求在每个逻辑断点处进行拆分，分成多个commits.
+
+多个逻辑上有意义的提交，有助于向审查者展示你的开发过程，以及你的想法。
+
+**请努力将逻辑上不同的想法分组到单独的提交中。**
+
+例如，如果你发现Feature-X需要一些重构才能适应，就做一个只进行那种重构的提交，
+然后再为Feature-X做一个新的提交。
+在提交数量上要找到一个平衡点。
+一个包含25个提交的请求仍然很难审查，所以要运用你的最佳判断。
+
+### 拆分PR
+
+或者，回到我们重构的例子，你也可以创建一个新分支，在那里进行重构，然后为那个功能发一个PR。
+
+如果你能从你的PR中，把单独的，可合并到主线的部分作为单独的PR来提交到主线，你就可以避免不断rebase的痛苦问题。
+
+DragonOS的仓库主线一直在更新，请你尽快提交小的PR、小的更改。（你的PR更早合并进主线的话，其他繁琐的事情就是别人的了）
+
+**多个小的请求通常比多个提交更好。**
+
+不要担心太多的小PR会淹没我们。我们宁愿有100个小的、明显的PR，也不愿有10个无法审查的庞然大物。
+
+我们希望每个PR都能独立工作，所以在拆分时，决定是作为独立的PR还是独立的commit时，要结合你的最佳判断。
+
+作为一个经验法则，如果你的请求与Feature-X直接相关，而不涉及其他内容，它应该可能是Feature-X请求的一部分。
+如果你能解释你为什么做看似无用的操作,比如：“我保证它使Feature-X的变更更容易”，我们可能就会接受你的PR。
+
+## 为修复和通用功能开启不同的PR
+
+**将与你正在开发的feature无关的更改放入不同的PR中。**
+
+通常，在你实现Feature-X的过程中，你会发现差的注释、命名不当的函数、糟糕的结构、薄弱的类型安全等问题。
+
+你绝对应该修复这些问题（或者至少请提出issue），但不要与你的特性放在同一个请求中。否则，你的差异将会有太多的变化，你的审查者将无法看到树木之外的森林。
+
+
+**寻找将功能提取出来的机会。**
+
+例如，如果你发现自己接触了很多模块，思考一下你在包之间引入的依赖关系。
+你正在做的一些事情能否变得更加通用，并从Feature-X包中移出并上移？
+你是否需要使用一个与其它包无关的函数或类型？
+如果是，就把这些代码单独封装/提出来！
+
+同样，如果Feature-X与上个月提交的Feature-W在形式上相似，并且你正在复制Feature-W中的一些棘手内容，考虑将核心逻辑提取出来，并在Feature-W和Feature-X中都使用它。
+
+（请在一个单独的commit或PR中这样做。）
+
+## 不要开启涵盖整个仓库的PR
+
+通常，一个新的贡献者会在仓库的许多地方发现一些问题，并提交一个PR一次性修复所有问题。
+
+也许最新的Rust版本中有一个很酷的新函数，每个人都应该使用，或者有一个最近被弃用的函数，应该用调用其替代函数来替换。有时，贡献者会运行linter或安全扫描器来查找问题，或者在注释或变量名中修复特定的拼写错误。
+
+这种方法的问题是，仓库的不同部分由不同的SIG维护，因此对这些不同部分的更改需要得到不同人的批准。一个包含20个单行更改、散布在仓库各处的PR可能最终需要5个或10个以上的批准才能合并。（尽管有少数人可以批准对仓库大部分内容的更改，但这些人通常是最忙碌、最难获得审查的，特别是当你是一个在社区内还没有联系的新贡献者时。）
+
+如果你真的想尝试让这样的PR合并，你最好的做法是将PR分解，把他拆分为每个它所涉及的SIG的单独PR。你可以查看仓库下的`triagebot.toml`文件，看看谁拥有那段代码，然后相应地将你的修改分为多个PR。
+
+## 注释很重要
+
+在你的代码中，如果有人可能不理解你为什么这么做（或者你以后会忘记为什么），那就加上注释。许多代码审查的评论都是关于这个确切的问题。
+
+如果你认为有一些非常明显的事情我们可以跟进，请添加一个TODO。
+
+阅读[代码风格指南]- 遵循这些关于注释的一般规则。
+
+## 测试
+
+没有什么比开始审查时发现测试不充分或缺失更令人沮丧的了。
+
+**如果你的PR测试不充分，或者压根没有测试，审查者会很恼火，或者根本不会审查你的代码！**
+
+非常少的PR可以在不触及测试的情况下修改代码。
+
+**如果你不知道如何测试Feature-X，请提问！** 我们将很高兴帮助你设计易于测试的东西，或者建议合适的测试用例。
+
+## Commit Message指南
+
+**请注意，PR的标题应该遵守“[约定式提交](#使用“约定式提交”)”的规范**
+
+PR评论不会出现在提交历史中。
+
+提交和它们的提交信息是您的PR中正在进行的更改的_“永久记录”_，它们的提交信息应该准确地描述_什么_和_为什么_。
+
+提交信息由两部分组成：主题和正文。
+
+主题是提交信息的首行，对于小或微不足道的更改通常只需要这部分。
+这些可以通过`git commit -m`或`--message`标志作为“单行”完成，但只有在可以用这几句话完全描述这个commit时，才可以这样做。
+提交信息的正文是当你运行`git commit`不带`-m`标志时，主题下方的文本部分，这将在你的编辑器中打开提交信息进行编辑。
+
+输入一些解释性的句子对于你的审查和整体后期的项目维护是非常有用的。
+
+```
+提交类型：这是提交信息的主题
+
+这里的任何文本都是提交信息的正文
+一些文本
+更多的文本
+...
+# 请输入你的更改的提交信息。以'#'开头的行将被忽略，空消息会终止提交。
+#
+# 在分支 example
+# 要提交的更改：
+#   ...
+#
+```
+
+使用以下指南来帮助编写格式良好的提交信息。
+
+- [使用“约定式提交”](#使用“约定式提交”)
+- [尝试将主题行保持在50个字符以内；不要超过72个字符](#尝试将主题行保持在50个字符以内-不要超过72个字符)
+- [提交信息主题的第一个词应该大写，除非它以小写符号或其他标识符开头](#提交信息主题的第一个词应该大写-除非它以小写符号或其他标识符开头)
+- [不要以句号结束提交信息主题](#不要以句号结束提交信息主题)
+- [在提交信息主题中使用祈使语气](#在提交信息主题中使用祈使语气)
+- [在提交信息正文前添加一个空白行](#在提交信息正文前添加一个空白行)
+- [不要在提交信息中使用GitHub关键词或(@)提及](#不要在提交信息中使用github关键词或-提及)
+- [使用提交信息正文来解释提交的_什么_和_为什么_](#使用提交信息正文来解释提交的_什么_和_为什么_)
+<!-- omit in toc -->
+
+### 使用“约定式提交”
+
+
+&emsp;&emsp;关于约定式提交的详细规范，在[Conventional Commit/约定式提交](https://www.conventionalcommits.org/zh-hans/v1.0.0/)网站中有详细介绍，在本节末尾将给出示例(摘自[Conventional Commit/约定式提交](https://www.conventionalcommits.org/zh-hans/v1.0.0/)网站)，可选择性阅读。我们做出以下特别说明：
+1. 由于DragonOS内核原则上仅通过系统调用接口保证对外可用性，而迄今为止(2024/04/22)，出于对软件生态的考量，DragonOS选择实现与Linux一致的系统调用，因此不会对`破坏性变更(BREAKING CHANGES)`做特殊说明，或者说，在当前开发环境中不会产生对用户产生显著影响的破坏性变更，因此无特殊需要，DragonOS内核不应使用诸如`feat!`来表示破坏性变更。(内核之外，例如dadk，仍需遵循规范)
+2. DragonOS社区严格遵循基于squash的工作流，因此我们并不强制要求PR中的每一个单独的commit都符合[Conventional Commit/约定式提交](https://www.conventionalcommits.org/zh-hans/v1.0.0/)，但是我们仍强烈建议使用。
+3. 关于scope: 如无特殊说明，以子模块/系统/目录名作为范围，例如代码变动是发生在`kernel/src/driver/net`中的特性追加，那么应当命名为`feat(driver/net):`，如果是发生在`kernel/src/mm/allocator`中，应当命名为`feat(mm)`，简而言之就是要尽可能简短的表现出所属模块，大多数情况下，不应使用超过两级的范围标识，例如`fix(x86_64/driver/apic)`是错误的，应当命名为`fix(x86_64/apic)`
+4. 在DragonOS内核代码仓库中的`issue checker`会对标题格式进行简单审查，如果不符合格式的将会被标记为`ambiguous`，贡献者们请按需修改
+5. 使用小写
+
+
+### 尝试将主题行保持在50个字符以内；不要超过72个字符
+
+50字符的主题行限制是为了保持消息摘要尽可能简洁。
+它应该只是足以描述正在做什么。
+72个字符的硬限制是为了与最大正文大小对齐。
+当使用`git log`查看仓库历史时，git会使用额外的空格填充正文文本。
+将宽度 控制 在72个字符可以确保正文文本在80列终端中居中并易于查看。
+<!-- omit in toc -->
+#### 提供额外上下文
+
+你可以使用更少的字符通过在提交信息前加上你PR影响的[类型]或[区域]来提供额外上下文。
+
+这些标签通常是DragonOS社区其他成员会理解的常用标签。
+
+**例如：**
+- `feat(mm/allocator): 添加xxxx分配器`
+- `feat(api)!: send an email to the customer when a product is shipped`
+- `fix(epoll): 修复epoll在xxx场景下无法唤醒目标进程的问题`
+
+这些可以在正文进一步阐述这个PR或者这个commit的内容。
+
+<!-- omit in toc -->
+### 提交信息主题的第一个词应该大写，除非它以小写符号或其他标识符开头
+提交信息主题就像一个缩写句子。
+第一个词应该大写，除非消息以符号、首字母缩略词或其他标识符开头，这些通常应该是小写的。
+<!-- omit in toc -->
+### 不要以句号结束提交信息主题
+这主要是为了节省空间，也有助于推动主题行尽可能短和简洁。
+<!-- omit in toc -->
+### 在提交信息主题中使用祈使语气
+祈使语气可以被认为是_“下达命令”_；它是一个**现在时态**的陈述，明确描述正在做什么。
+**好的例子：**
+- 修复y中的x错误
+- 将foo添加到bar
+- 撤销提交“baz”
+- 更新PR指南
+
+**不好的例子**
+- 修复了y中的x错误
+- 添加了foo到bar
+- 撤销了错误的提交“baz”
+- 更新了PR指南
+- 修复更多问题
+
+关于形成祈使语气的提交主题的一般准则是，它应该能填充这个句子：
+
+```
+如果应用，这个提交将 <你的主题行在这里>
+```
+
+**例子：**
+- _如果应用，这个提交将_ **修复y中的x错误**
+- _如果应用，这个提交将_ **将foo添加到bar**
+- _如果应用，这个提交将_ **撤销提交“baz”**
+- _如果应用，这个提交将_ **更新PR指南**
+
+<!-- omit in toc -->
+### 在提交信息正文前添加一个空白行
+Git使用空白行来确定提交信息的哪部分是主题和正文。
+主题前的文本是主题，而主题后的文本被认为是正文。
+<!-- omit in toc -->
+### 将提交信息正文 wrap 在72个字符
+Git的默认列宽是80字符。
+当查看git日志时，git会在正文文本周围添加额外的空格。
+这将为您留下76个可用字符的空间，但是文本将显得“偏斜”。
+为了使文本在80列终端中居中并易于查看，Git会使用相同的空格量在另一侧进行人工填充，结果在每行上可用72个字符。
+想象一下它们是word文档的边距。
+<!-- omit in toc -->
+### 不要在提交信息中使用GitHub关键词或(@)提及
+<!-- omit in toc -->
+#### GitHub关键词
+在提交信息中使用[GitHub关键词]后跟`#<问题编号>`引用将自动在您的PR上应用`do-not-merge/invalid-commit-message`标签，从而阻止它被合并。
+[GitHub关键词]在PR中用于关闭问题是一种便利，但当在提交信息中使用时，可能会产生意外的副作用；通常关闭了它们不应该关闭的东西。
+**被阻止的关键词：**
+- close
+- closes
+- closed
+- fix
+- fixes
+- fixed
+- resolve
+- resolves
+- resolved
+<!-- omit in toc -->
+#### (@)提及
+在提交信息中的(@)提及将向该用户发送通知，并且每当PR更新时，都会持续发送。
+<!-- omit in toc -->
+### 使用提交信息正文来解释提交的_什么_和_为什么_
+提交和它们的提交信息是您的PR中正在进行的更改的_“永久记录”_。
+描述为什么事情发生了变化以及它可能产生的影响。
+你为审查者和下一个需要接触你代码的人提供了上下文。
+如果某个东西正在解决一个bug，或者是对某个特定问题的响应，你可以在正文本身中链接它作为参考。
+这些类型的面包屑对于追踪未来的bug或回归至关重要，并进一步帮助解释为什么这个提交被创建。
+**其他资源：**
+- [如何编写Git提交信息 - Chris Beams](https://chris.beams.io/posts/git-commit/)
+- [分布式Git - 贡献给项目（提交指南）](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)
+- [50/72规则是怎么回事？ - Preslav Rachev](https://preslav.me/2015/02/21/what-s-with-the-50-72-rule/)
+- [关于Git提交信息的笔记 - Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
+
+## 适当的回击是可以的
+
+有时候审查者会犯错。如果你有充分的理由坚持自己的做法，那么你有权与审查者讨论所请求更改的优点。审查者和被审查者都应该以礼貌和尊重的方式讨论这些问题。
+你可能会被推翻，但你也可能会成功。我们都是一些相当理性的人。
+开源项目的另一个现象（任何人都可以对任何问题发表评论）是“狗群效应”——你的PR收到了来自众多人的众多评论，使得跟进变得困难。在这种情况下，你可以询问主要审查者（分配者）是否希望你创建一个新的分支来清理所有评论。你不必修复每一个评论者提出的所有问题，但应该对合理的评论给出解释。
+
+## 琐碎的编辑
+
+每个进来的PR都需要被审查、检查，然后合并。
+尽管自动化可以帮助处理这一点，但每个贡献也都有工程成本。因此，如果你发现文件中有一个语法错误或拼写错误，很可能该文件中还有更多类似的错误，你可以通过检查格式、检查链接是否有效以及修复错误，然后一次性提交所有修复，从而使你的请求发挥最大的作用。
+
+**一些需要考虑的问题：**
+
+* 文件是否还可以进一步改进？
+* 这次琐碎的编辑是否大大提高了内容的质量？
+
+## 工作流
+
+DragonOS社区使用`@dragonosbot`来执行自动化的工作流。
+
+以下是一个PR从创建到合并的过程
+
+1. 创建PR
+1. `@dragonosbot assign` 来分配审查者
+1. Reviewer审查了你的代码，并且提出了意见。接着，reviewer需要在审查意见的末尾添加一行`@dragonosbot author`，告知机器人把PR的状态更改为“等待作者修改”。
+1. 把你的更改推送到当前分支
+1. 添加评论，描述你的更改，并且在评论的最后一行添加`@dragonosbot ready`
+1. 重复上述步骤直到审查无问题后，具有合并权限的审查者会将您的代码合并到主线。
+
+
+
+
+[GitHub工作流程]: /contributors/github-workflow.md
+[贡献者指南]: /contributors/README.md
+[为DragonOS社区作出贡献]: /contributors/README.md
+[社区沟通渠道]: /communication/README.md
+[代码风格指南]: /contributors/code-style.md
+
+

mentorship/README.md

@@ -1,3 +1,34 @@
 # 导师制
 
-TODO
+当你准备参与，或刚刚开始参与DragonOS社区的开发时，也许你对项目本身，以及社区流程规范并不熟悉。我们的导师制
+正是为了帮助你入门，参与到DragonOS社区的开发之中。
+
+对于DragonOS开源社区这个大家庭来说，随着项目的日益壮大，我们急需一批又一批高质量的贡献者源源不断地加入，
+我们真心期待你能够长久地与我们并肩前行，共同书写这段精彩的旅程！共同打造完全自主可控的数字化未来！
+
+## 指导计划
+
+DragonOS社区的导师制目前包含以下类型的指导：
+
+- [教育学习课程]
+- [基于项目的指导]
+- [开源之夏]
+
+您可以点击上面的链接，进入对应页面详细了解。
+
+**推荐路线**：先自学Rust语言知识后，选择1到2个[教育学习课程]进行学习，接着通过“[基于项目的指导]”来熟悉真正的社区开发。
+
+## 学员指南
+
+这里有一份[指南](/mentorship/mentee-guide.md)来帮助您报名成为学员
+
+## 想成为导师？
+
+成为导师，帮助更多的人加入DragonOS社区！
+
+请见[导师指南]
+
+[教育学习课程]: /mentorship/programs/educational-learning-courses.md
+[基于项目的指导]: /mentorship/programs/project-based-mentorship.md
+[开源之夏]: /mentorship/programs/ospp.md
+[导师指南]: /mentorship/mentor-guide.md

mentorship/mentee-guide.md

@@ -0,0 +1,39 @@
+# 学员指南
+
+这篇文章帮助您成为一名学员。
+
+## 指导计划
+
+DragonOS社区的导师制目前包含以下类型的指导：
+
+- [教育学习课程]
+- [基于项目的指导]
+- [开源之夏]
+
+您可以点击上面的链接，进入对应页面详细了解。
+
+**推荐路线**：先自学Rust语言知识后，选择1到2个[教育学习课程]进行学习，接着通过“[基于项目的指导]”来熟悉真正的社区开发。
+
+
+## 对学员的期望
+
+学员应该：
+
+- 请记住，我们的导师都是志愿者，要善良、友好。
+- 如果您与导师之间出现任何问题，请告知项目管理委员会([pmc@dragonos.org])，例如违反[行为准则]（CoC）或长时间（大约 1 周左右）没有回应。
+- 提供关于DragonOS社区导师制本身，或您的导师的反馈，让我们知道是否有任何我们没有满足您的需求的地方。
+  毕竟这个项目是为了您而建的，我们想倾听您的诉求。
+
+## 报名参加项目
+
+- [教育学习课程]： 请您在自学完Rust语言之后，学习该课程。您可以在bbs上发帖，或者是联系每个课程的导师，以询问问题。**对于课程内容本身的疑惑，** 我们建议您在论坛发帖后，把帖子链接发送给导师，让导师在论坛回复您。这样能够减少很多重复工作。（大家的问题可能是相近的）
+
+- [基于项目的指导]： 请您在自学或与导师沟通后，撰写项目方案书，并发送给导师，请求导师对方案进行审核。
+  当导师确认方案无问题后，请将方案书发布在bbs上，并在mentorship仓库内对应的issue下评论帖子的链接。请提醒导师把任务状态更新为“In-progress”，并让他在issue内的“学员”一栏，`@您的GitHub账号`。
+
+
+[教育学习课程]: /mentorship/programs/educational-learning-courses.md
+[基于项目的指导]: /mentorship/programs/project-based-mentorship.md
+[开源之夏]: /mentorship/programs/ospp.md
+[pmc@dragonos.org]: mailto:pmc@dragonos.org
+[行为准则]: /contributors/code_of_conduct.md

mentorship/mentor-guide.md

@@ -0,0 +1,87 @@
+# 导师指南
+
+目前，DragonOS项目已经初具体量，没有人能回答所有的问题。贡献者们依靠我们的文档、PR、issue、论坛的帖子来了解项目，与已有的开发者进行互动，从而快速上手。贡献者希望讨论技术细节、前景，或者是想知道如何为DragonOS贡献更大的价值。
+
+**导师这一角色，能够帮助贡献者们在DragonOS社区中提高生产力。**
+
+在DragonOS社区中，您有多种方式来成为导师。最简单的方式就是，倾听他人的问题，然后与他讨论，促进他解决这些问题。
+
+但是，由于我们考虑到每个人的时间是有限的（对于讨论双方而言都是），您很难抽出稳定的时间来指导某人，因此，DragonOS社区提供了几种类型的[指导计划]，在这些指导计划下，我们为您设置了沟通的框架，规定了您的职责以及对您的期望。
+
+您扮演着2个角色，分别是“教练”以及“顾问”。您不一定知道问题的所有答案，但是您需要告知学员如何去找到这些答案（比如找到解决问题所需的资源、解决问题的潜在方式、要联系的人员等等）
+
+请查看我们的[指导计划]，了解更多的详细内容。
+
+**如果您想好了，欢迎填写[此表格](TODO)来报名成为导师**
+
+
+## 您的责任，以及社区对您的期望
+
+以下内容适用于所有的指导计划：
+
+- 您的目标是**成为一名向导，而不是老师**。如果您有时间教某人 Rust语言 的基础知识，我们欢迎您这样做。但是这不是必须的！
+- **梳理问题：** [社区成员资格]文档里面的许多职级都要求您帮助贡献者梳理问题。举几个例子：
+  - 为新贡献者挑选不跨越多个 SIG 的问题，以便他们快速入门
+  - 告诉他们，哪些问题/帖子/PR需要特别关注（对于解决他们的问题有帮助）
+- 向学员介绍学习资源，介绍可以学员的问题提供帮助的人员。您不需要了解学员可能感兴趣的所有事情，但认识可以提供帮助和帮助介绍的人很重要。
+- 帮助贡献者提高生产力。
+- **耐心与同理心。** 人们在重复中学习，作为导师，我们不应期望学员能够立刻达到我们所有的期望。通过放下期望和偏见，再加上一点同情心，我们就能获得更多的耐心。
+- 提供建设性的反馈，传递您在开源工作过程中学到的东西。
+  - 例如，如果您的学员正在做一些很酷的事情，鼓励他们在博客里/bbs上面写下它！
+- **及时回复：** 我们期望您能在1天内回复您的学员的消息。长时间的不回复，或者是“朕已阅”的情况，会让人感到沮丧。哪怕您很忙，我们也期望您能回复学员一句“我现在很忙，xx时间之前一定回复你”。
+- 一起玩得开心，一起学习！
+
+
+## 成为导师的好处
+
+- **为DragonOS社区创造价值：** 帮助社区贡献者快速成长，提升大家的参与感和获得感。
+- **为您的SIG/WG/子项目带来新的成员：** 培养您所在的社区团体的优质贡献者，让您所在的社区团体更加活跃。
+- **为您的个人发展：** 成为项目内外的技术领导者，培养您与人沟通的技能。
+- **提升对项目的认识：** 在实践中了解DragonOS社区在流程、文档、技术等方面的漏洞/问题点。
+- **社区认可！** DragonOS社区将为优秀的导师颁发证书。
+
+
+## 很重要的事情
+
+- 您必须了解DragonOS社区的运作方式，并且在技术上有宏观的认识。
+- 您必须花相当的时间与您的学院进行交流沟通。
+- 只有新的贡献者才需要被指导。
+
+## 各个指导计划的导师职责
+
+### [教育学习课程]
+
+你需要：
+
+- 每周至少在DragonOS社区论坛以及社区的GitHub仓库上面呆1~2小时，回答问题
+- 每两周组织一次10-15分钟的小组会议，以跟进你的学员的进度
+- 帮助建立小组间的团结：最简单的方式就是引导学员与合适的人进行沟通，或者引导学员在bbs上发布自己的学习笔记/源码分析。
+
+**请告知学员：**学员要对自己的成长和能力提升而负责，因为这是一个半结构化、自定进度的项目；导师在此的作用是帮助他们指引方向。导师与学员分享方法论、资源、技巧和经验，帮助他们进步。
+
+### [基于项目的指导]
+
+- 作为导师，每周可能需要花费2~3小时的时间。这具体取决于学员的项目范围
+- 在项目开始之前：
+  - 进行项目申报，编写任务内容、发布任务。
+  - 为潜在的参与者提供建议（基于他们的能力来推荐一些前置的小任务）
+  - 通过bbs与感兴趣的候选人交谈。与他们分享项目详情、目标和一些实施想法。
+- 在项目期间：
+  - 在bbs和GitHub issue上，与学员进行讨论（要求学员把方案放到公开的位置，您通过公开的方式对方案发表您的评审意见）
+  - 与你的学员沟通，制定开发计划。确保你确立了实际的工作目标和时间线期望。并把开发计划发布到该任务在[mentorship仓库]下的issue里面。
+  - 提供指导，如指向有用的文档、代码审查等。
+  - 留出时间进行每周的线上文字交流或电话会议，同步跟踪进展，这取决于你的喜好。
+  - 跟踪徒弟的进度，并让他们了解自己的状况。确保你尽早提供反馈。**请在24小时内回复您的学员的问题~**
+- 在项目结束后：
+  - 在适当的沟通渠道中分享项目的结果。
+  - 将项目开展过程中的您遇到的问题/想法，通过邮件告知pmc成员：[pmc@dragonos.org]
+  - 向你的学员推荐在当前项目里面，下一步应该做什么。或您认为他们在DragonOS社区中可能能做什么。
+  - 在[mentorship仓库]中标注该项目已经结题。
+
+
+[指导计划]: /mentorship/README.md
+[社区成员资格]: /governance/community-membership.md
+[教育学习课程]: /mentorship/programs/educational-learning-courses.md
+[基于项目的指导]: /mentorship/programs/project-based-mentorship.md
+[mentorship仓库]: TODO
+[pmc@dragonos.org]: mailto:pmc@dragonos.org

mentorship/programs/educational-learning-courses.md

@@ -0,0 +1,14 @@
+# 教育学习课程
+
+社区有一些教学性质的课程/任务，你能够通过这些小任务来熟悉DragonOS，以及熟悉Rust语言。
+
+每个课程都有几名导师，并且我们鼓励有志于帮助其他人入门的贡献者，主动成为课程导师。
+
+教育学习课程位于[mentorship仓库]内 （TODO，还没创建这个仓库）.
+
+## 想成为导师？
+
+请转到[导师指南]！
+
+[mentorship仓库]: TODO
+[导师指南]: /mentorship/mentor-guide.md

mentorship/programs/ospp.md

@@ -0,0 +1,4 @@
+# 开源之夏
+
+// TODO 介绍DragonOS在2023、2024的开源之夏里面的项目
+

mentorship/programs/project-based-mentorship.md

@@ -0,0 +1,29 @@
+# 基于项目的指导
+
+基于项目的指导，能帮助你熟悉社区开发，融入社区！并且，当您完成项目的时候，将能够收获来自社区的“项目完成证书”！
+
+## 项目来自哪里？
+
+- **已经发布的项目：** 您可以在[mentorship仓库]的issue内，筛选已经发布了的，且无人开发的项目。
+- **寻找导师申报项目：** SIG或者工作组有时会在社区内发布一些课题，或者是有人在仓库的issue里面报告了一些BUG。这些都是潜在的项目。您可以联系来自对应的SIG的导师，让他们在[mentorship仓库]发布项目，并指定由您进行开发。
+- **自行申报项目：** 如果已有的issue里面没有涵盖您感兴趣的课题，您可以先在对应的仓库的issue或者是[DragonOS的bbs]上发帖，与大家充分讨论您的想法，如果没有什么太大的问题，那就能进入开发环节。（可能需要进入RFC流程）
+
+## 项目指导流程
+
+1. **项目导师:** 在[mentorship仓库]内提出issue，发布项目。
+2. **被指导者:** 在对应的issue下评论“报名项目”，并通过项目导师的邮箱与其联系。
+3. **项目导师:** 导师确认后，更新issue信息，把中选学生信息填写到issue内。
+4. **项目导师:** 导师需要根据项目进展，不断地更新issue的label以及issue的内容，以表示项目的状态。
+5. **被指导者:** 在导师的指导下完成项目，并把相关的PR链接填写到issue内（如果有多个PR，请使用列表的形式填写）
+6. **项目导师:** 确认结项，更新label。
+7. **SIG负责人:** 接着，项目导师所属的任一SIG的负责人审查成果后，在issue下评论“Approved”。
+8. **项目促进群:** 审查通过后，参与者能够在社区贡献网站上查询、下载结项证书。（该网站正在开发）
+
+
+## 想成为导师？
+
+请转到[导师指南]！
+
+[mentorship仓库]: TODO
+[DragonOS的bbs]: https://bbs.dragonos.org.cn
+[导师指南]: /mentorship/mentor-guide.md

package.json

@@ -18,8 +18,8 @@
   },
   "homepage": "https://github.com/DragonOS-Community/Community#readme",
   "devDependencies": {
-    "@vuepress/bundler-vite": "^2.0.0-rc.11",
-    "@vuepress/theme-default": "^2.0.0-rc.30",
-    "vuepress": "^2.0.0-rc.11"
+    "@vuepress/bundler-vite": "^2.0.0-rc.14",
+    "@vuepress/theme-default": "^2.0.0-rc.37",
+    "vuepress": "^2.0.0-rc.14"
   }
 }