Skip to content

Commit

Permalink
Update doc
Browse files Browse the repository at this point in the history
  • Loading branch information
ccmywish committed Dec 13, 2024
1 parent 13f6bc6 commit d180414
Show file tree
Hide file tree
Showing 2 changed files with 58 additions and 5 deletions.
42 changes: 42 additions & 0 deletions doc/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -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 后自己立即合并即可。之所以多此一举,是因为这能够显式地记录代码的加入过程,其相当于一份文档方便未来的自己和他人查阅
21 changes: 16 additions & 5 deletions doc/MAINTAINERS.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down

0 comments on commit d180414

Please sign in to comment.