README_zh.md

fleximq RFCs (提议征集)

本仓库用于 fleximq 协议的提议征集 (RFCs)。它是提议、讨论和最终确定 fleximq 协议新特性、增强功能或任何重大变更的主要平台。

目的

RFC (Request for Comments) 流程旨在：

• 为新想法和协议修改提供透明且一致的途径。
• 鼓励社区参与和建立共识。
• 维护设计决策及其理由的全面记录。

贡献工作流程

1. 想法与讨论 (可选但推荐)：

   • 在撰写完整的 RFC 之前，您可能希望在本仓库的 Issues 部分或其他社区渠道讨论您的想法，以收集初步反馈。

2. Fork 与创建：

   • Fork 本 fleximq/rfcs 仓库。
   • 将 0000-template.md 文件复制到 text/ 目录下的一个新文件，命名为 0000-my-descriptive-name.md。（0000 前缀是临时的；合并时维护者将分配一个 RFC 编号）。

3. 撰写 RFC：

   • 填写您的 RFC 文档，清晰地概述提议。关键部分通常包括：
     • 摘要： 提议的简要概述。
     • 动机： 为什么需要此更改？它解决了什么问题？
     • 详细设计： 详细描述新特性或更改。
     • 缺点： 有哪些潜在的缺点或权衡？
     • 替代方案： 考虑过哪些其他方法？
     • 未解决的问题： 哪些方面仍有待解决？

4. 提交 Pull Request (PR)：

   • 从您的 fork 创建一个 Pull Request 到 fleximq/rfcs 仓库的 main (或 master) 分支。
   • PR 标题应具有描述性，例如："RFC: 关于弹性消息传递的提议"。
   • PR 描述应链接到您的 RFC 文档。

5. 审查与迭代：

   • 社区成员和维护者将通过 PR 审查您的 RFC。
   • 准备好根据反馈讨论、澄清和迭代您的提议。

6. 接受或拒绝：

   • 经过讨论和达成共识（或项目维护者做出决定）后，RFC 将会：
     • 被接受： PR 被合并。RFC 文档被分配一个官方编号，其状态被更新。被接受的 RFCs 将构成 fleximq/spec 仓库中变更的基础。
     • 被拒绝： PR 被关闭并附带解释。
     • 被推迟： 如果想法很好但当前不适合实施，PR 可能会被关闭。

RFC 状态

RFC 可以处于以下状态之一 (您可以在 RFC 文档中注明)：

• 草稿/提议中 (Draft/Proposed)： 提交审查的初始版本。
• 审查中 (In Review)： 正在积极讨论和审查。
• 已接受 (Accepted)： 已批准并合并。
• 已实施 (Implemented)： RFC 中描述的更改已合并到 fleximq/spec 仓库中（作为草案或正式规范）。
• 已拒绝 (Rejected)： RFC 已被拒绝。
• 已推迟 (Deferred)： RFC 被推迟以供将来考虑。
• 已撤回 (Withdrawn)： 作者已撤回 RFC。

文件位置

• RFC 模板： 0000-template.md
• RFC 文档： text/

我们期待您的贡献！