From d18041429cbae7f34d8e24cf0ecc3b0a916eeba6 Mon Sep 17 00:00:00 2001
From: Aoran Zeng <ccmywish@qq.com>
Date: Fri, 13 Dec 2024 20:58:27 +0800
Subject: [PATCH] Update doc

---
 doc/CONTRIBUTING.md | 42 ++++++++++++++++++++++++++++++++++++++++++
 doc/MAINTAINERS.md  | 21 ++++++++++++++++-----
 2 files changed, 58 insertions(+), 5 deletions(-)
 create mode 100644 doc/CONTRIBUTING.md

diff --git a/doc/CONTRIBUTING.md b/doc/CONTRIBUTING.md
new file mode 100644
index 0000000..5a1e259
--- /dev/null
+++ b/doc/CONTRIBUTING.md
@@ -0,0 +1,42 @@
+# 贡献说明
+
+## 分支
+
+- `gh-pipeline`：仅仅在发布版本时由 `@ccmywish` 推送，触发编译到 GitHub Releases 中
+- `gh-site`：`chsrc.run` 的工作分支，由 `@ccmywish` 推送
+- `main`: stable，代码一定是可以编译运行的，我们假设 end users 在其他条件都得不到二进制时，会自己编译这个分支来运行 `chsrc`
+- `dev`：开发分支，工作分支，在此分支上解决冲突
+
+<br>
+
+## 提交与审阅
+
+### 一个简单的 Bug
+
+一个简单的 Bug fix，有写权限的维护者可以直接推送到主仓库的 `dev` 分支
+
+<br>
+
+### 不太容易修复的 Bug 以及新功能
+
+这里要分两种情况考虑。（1）recipe 相关的 （2）framework 相关的
+
+（1）
+
+1. **如果你是 recipe director，则你完全负责这个 recipe，如果你拥有写权限，你可以直接推送代码到 `dev` 分支**
+2. 如果你是 recipe maintainer，则你需要参考 [MAINTAINERS.md](./MAINTAINERS.md)，如果只有你一个人，且你拥有写权限，你可以直接推送代码。如果有多人，则需要提一个 issue，介绍方案，然后 @ 所有 maintainer 来 review
+
+---
+
+（2）
+
+1. 需要先搜索你修改的部分涉及到的 recipe，然后提 issue @ 所有相关的 recipe maintainer 来 review
+2. 如果涉及了所有 recipe，则 @ framework maintainer，而无需把所有 recipe 的 maintainer 都喊过来，但是如果觉得有必要，可以 @ 任意你觉得有能力 review 和能给出建议的人来 review
+
+<br>
+
+### 最好总是 issue 或 PR
+
+对于有写权限的维护者来说，即使是能够直接推代码，最好也都先提 issue 或 PR，因为这样能够让大家知道代码发生了哪些变动。
+
+如果你觉得要和大家讨论，则 issue；如果你觉得没有讨论的必要了，则直接 PR 后自己立即合并即可。之所以多此一举，是因为这能够显式地记录代码的加入过程，其相当于一份文档方便未来的自己和他人查阅
diff --git a/doc/MAINTAINERS.md b/doc/MAINTAINERS.md
index 486cf91..8be3e19 100644
--- a/doc/MAINTAINERS.md
+++ b/doc/MAINTAINERS.md
@@ -2,31 +2,42 @@
 
 作为该语言的资深用户、该软件的专家、镜像站维护人员等，你总是对镜像站和源的可用状态拥有一手信息，我们需要你的帮助。如果想要达到最理想的维护状态，每一个 recipe 都需要有专人长时间维护。所以我们在这个文件记录的是愿意**长期**维护的人，如果是一次性提交代码，只需要在对应 recipe 的文件标头中记录即可。
 
-一个target的协作者可分为：
+一个 recipe 的协作者可分为：
 
 1. **Director**
 
-    负责人，对一个 recipe 完全负责。
+    负责人：对一个 recipe 完全负责，有写权限时可以直接推代码
 
     **目前项目的发展阶段还处于 *外行实现内行* 的情况，比如 Homebrew recipe，实现者根本不是 Homebrew 的真实用户，只是根据各种文档来实现，然后等待用户反馈。所以这里当前的实现者最多只能是 Maintainer，无法承担 Director 的责任**
 
 
 2. **Maintainers**
 
-    维护者，实现和持续维护 recipe
+    维护者：实现和持续维护 recipe，需要和 Director 一起 review 代码。可参考 [CONTRIBUTIING.md](./CONTRIBUTING.md) 了解项目是如何进行提交和审阅代码的
 
 
 3. **Observers**
 
-    观察者，对该 target 持续反馈和关注的用户。如果你觉得你无法承担作为维护者的责任，可以退而求其次作为观察者积极参与其中。
+    观察者：对该 target 和 recipe 持续反馈和关注的用户。如果你觉得你无法承担作为维护者的责任，可以退而求其次作为观察者积极参与其中
 
-考虑到真正参与维护的人并不多，所以上述人数均不设限。
+<br>
+
+**项目采用申请制，请提交 PULL REQUEST 在该文件中添加自己，并在 [issue #130](https://github.com/RubyMetric/chsrc/issues/130) 留言。考虑到真正参与维护的人并不多，所以上述人数均不设限。**
 
 `@`后面跟的是GitHub账户名，如 `@ccmywish`。若使用Gitee账号，则使用 `@gitee:ccmywish`。对我们来说，镜像站成员非常重要，所以请额外标注身份，如 `@username [TUNA]`
 
 <br>
 
 
+## Framework
+
+1. **Director**: `@ccmywish` `@gitee:G_I_Y`
+2. **Maintainers**:
+3. **Observers**:
+
+<br>
+
+
 ## 编程语言
 
 ### Ruby