# RFCS

**Repository Path**: luyu-community/rfcs

## Basic Information

- **Project Name**: RFCS
- **Description**: 请求意见稿
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-08-25
- **Last Updated**: 2022-05-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 什么是RFC

`RFC`（`Request For Comments`，请求意见稿）的目的是通过从利益相关者和专家那里获得反馈，并广泛地交流设计变更，从而促进社区成员积极地参与开发工作。

最初由互联网工程任务组（`Internet Engineering Task Force，IETF`）用来记录互联网规范、协议、过程等。

# 为什么需要RFC

一个清晰的 RFC 流程对于开源项目来说非常重要，可以让维护人和想要为开源项目做贡献的人都节省时间。

对于维护人来说，有一个正式的方式可以让任何有意愿改进项目的人来提交其想法和方案，可以集思广益，广泛的收集改进建议。同时，这些改进建议会被进行广泛的讨论和修改，保证最终走完流程之后的建议是切实可行的，而不会无谓的浪费维护人的时间。

对于贡献者来说，有一个清晰的流程来提交自己对项目的改进想法，并一步一步推进，直到在项目中落地。

RFC流程几乎是所有大型开源项目必备的标准流程，当然各个项目会根据自己的情况，执行细节上不尽相同，甚至会随着项目的发展进行修订。

# Luyu RFCs

陆羽跨链协议的实现包含公共组件和各种链的插件。

公共组件有：`Account Manager`，`luyu-java-sdk`, `Luyu Protocol`和`Router`。

公共组件相关的普通`bug fix`或者文档的修改按照普通的 `GitHub PR` 流程即可。各种链的插件的修改也可以按照这个流程。

但是，协议相关的修改，一定要经过充分的讨论和论证，并由整个开发团队达成一致结果。

`RFC` 处理流程就是为了保证协议的修改有一个一致的、可控的路径，以便开发团队以及相关开发者能够对陆羽跨链协议的发展方向有清晰的认识。

## 准备工作

在大家都不了解你的想法的情况下，匆忙提出的 `RFC` 可能会受到大家的冷落。不符合陆羽跨链协议发展路线的 `RFC` 可能最终会被舍弃，导致前功尽弃。

因此，最好是先在一些非正式场合抛出你的想法，与开发者一起讨论，确认想法是可行的。比如在社区微信群，或者在本仓库的 [issues](https://gitee.com/luyu-community/rfcs/issues) 中提 `issue`。

## 处理过程

`RFC` 格式为 `markdown` 文本文件，具体格式可以参见 `rfcs` 目录下的 `rfc-template`。

1. `fork` 当前仓库。
2. 参考模板文件，创建具体的 `rfc` 文件并补充相关内容。
   
   2.1. 编号为四位自增的数字，自行在当前最新的编号后加一。

   2.2. 每个 `rfc` 一个文件夹，以方便存放插图等附件，文件夹名字与 `rfc` 文件名字保持一致。

   2.3 分类有 `Informational` 和 `Protocol`。后者为协议级别的变更，前者为一般的信息性内容，比如白皮书，发展路线等。

   2.4 状态初始为 `Draft`，经过讨论修改变为 `Accepted`。如果后续被废弃，则变为 `Obsolete`。如果涉及代码实现，在实现完成后变更为 `Implemented`。
3. 提交 `PR`。社区成员在 `PR` 中进行讨论，作者根据反馈进行内容修订。
4. 如果 `rfc` 得到开发者的一致认同，或者在半数以上开发者发表过意见之后的两周内没有新的建议，则表示接受。
5. 如果 `rfc` 提出两周之后，没有任何开发者参与讨论，则自动关闭 `PR`，表示拒绝。

## 参与角色

* `rfc` 作者。发起编写 `rfc` 并积极推动其得到接受和实施的一个或者多个社区成员。
* `rfc` 编辑。负责审查并判断是否采纳 `rfc` 的一个责任人或者一个委员会。目前社区人员比较少，暂定为包含所有核心开发者的团队。
* 参与者。参与讨论并给出各种的社区成员。

## 实施

协议类型的 `rfc` 在接受之后通常需要修改公共组件。

相关的代码修改按照普通的 `GitHub PR` 流程进行，但是要在其中关联已经接受的 `rfc` 的相关链接。

检视人员要确保其代码实现与已经接受的 `rfc` 中的方案描述是一致的。

公共组件代码修改合并之后，还要修改各个链的插件的实现。直到所有仍在维护中的插件完成代码更新，才会在之后的版本中正式发布该特性，所以 `rfc` 的实施会是一个比较漫长的过程。

其中有些 `rfc` 可能会因为依赖其他 `rfc`，或者有更重要的 `rfc` 需要实施，排期会往后延。

`rfc` 的作者不一定要参与后续的实施环节，但是非常欢迎作者参与相关 `PR` 的代码检视。


## 参与贡献

欢迎大家参与跟陆羽跨链协议有关的任何方面的讨论，并给出您宝贵的建议。

地点可以是社区微信群，亦或本组织下任何仓库的 `issues`区和 `PR`区。