Update doc
Some checks are pending
Publish AUR Package (chsrc-git) / publish (push) Waiting to run

This commit is contained in:
Aoran Zeng 2024-12-13 20:58:27 +08:00
parent 13f6bc63c8
commit d18041429c
No known key found for this signature in database
GPG Key ID: 8F8BA8488E10ED98
2 changed files with 58 additions and 5 deletions

42
doc/CONTRIBUTING.md Normal file
View File

@ -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 以及新功能
这里要分两种情况考虑。1recipe 相关的 2framework 相关的
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 后自己立即合并即可。之所以多此一举,是因为这能够显式地记录代码的加入过程,其相当于一份文档方便未来的自己和他人查阅

View File

@ -2,31 +2,42 @@
作为该语言的资深用户、该软件的专家、镜像站维护人员等,你总是对镜像站和源的可用状态拥有一手信息,我们需要你的帮助。如果想要达到最理想的维护状态,每一个 recipe 都需要有专人长时间维护。所以我们在这个文件记录的是愿意**长期**维护的人,如果是一次性提交代码,只需要在对应 recipe 的文件标头中记录即可。 作为该语言的资深用户、该软件的专家、镜像站维护人员等,你总是对镜像站和源的可用状态拥有一手信息,我们需要你的帮助。如果想要达到最理想的维护状态,每一个 recipe 都需要有专人长时间维护。所以我们在这个文件记录的是愿意**长期**维护的人,如果是一次性提交代码,只需要在对应 recipe 的文件标头中记录即可。
一个target的协作者可分为: 一个 recipe 的协作者可分为:
1. **Director** 1. **Director**
负责人,对一个 recipe 完全负责。 负责人:对一个 recipe 完全负责,有写权限时可以直接推代码
**目前项目的发展阶段还处于 *外行实现内行* 的情况,比如 Homebrew recipe实现者根本不是 Homebrew 的真实用户,只是根据各种文档来实现,然后等待用户反馈。所以这里当前的实现者最多只能是 Maintainer无法承担 Director 的责任** **目前项目的发展阶段还处于 *外行实现内行* 的情况,比如 Homebrew recipe实现者根本不是 Homebrew 的真实用户,只是根据各种文档来实现,然后等待用户反馈。所以这里当前的实现者最多只能是 Maintainer无法承担 Director 的责任**
2. **Maintainers** 2. **Maintainers**
维护者,实现和持续维护 recipe 维护者:实现和持续维护 recipe需要和 Director 一起 review 代码。可参考 [CONTRIBUTIING.md](./CONTRIBUTING.md) 了解项目是如何进行提交和审阅代码的
3. **Observers** 3. **Observers**
观察者,对该 target 持续反馈和关注的用户。如果你觉得你无法承担作为维护者的责任,可以退而求其次作为观察者积极参与其中 观察者:对该 target 和 recipe 持续反馈和关注的用户。如果你觉得你无法承担作为维护者的责任,可以退而求其次作为观察者积极参与其中
考虑到真正参与维护的人并不多,所以上述人数均不设限。 <br>
**项目采用申请制,请提交 PULL REQUEST 在该文件中添加自己,并在 [issue #130](https://github.com/RubyMetric/chsrc/issues/130) 留言。考虑到真正参与维护的人并不多,所以上述人数均不设限。**
`@`后面跟的是GitHub账户名`@ccmywish`。若使用Gitee账号则使用 `@gitee:ccmywish`。对我们来说,镜像站成员非常重要,所以请额外标注身份,如 `@username [TUNA]` `@`后面跟的是GitHub账户名`@ccmywish`。若使用Gitee账号则使用 `@gitee:ccmywish`。对我们来说,镜像站成员非常重要,所以请额外标注身份,如 `@username [TUNA]`
<br> <br>
## Framework
1. **Director**: `@ccmywish` `@gitee:G_I_Y`
2. **Maintainers**:
3. **Observers**:
<br>
## 编程语言 ## 编程语言
### Ruby ### Ruby