Skip to content

Latest commit

 

History

History
96 lines (58 loc) · 6.1 KB

README.zh-cn.md

File metadata and controls

96 lines (58 loc) · 6.1 KB
Raw

LCUI RFCs

中文/English

许多改动，包括错误修复和文档改进，都可以通过正常的 GitHub/Gitee 拉取请求工作流程实施和审查。

虽然有些改动是“实质性的”，但我们要求这些改动经过一些设计过程，并在 LCUI 核心团队中达成共识。

“RFC”（征求意见）流程旨在为新功能进入项目提供一致且受控的路径。

RFC 生命周期

  • 待处理：当 RFC 作为 PR 提交时。
  • 已生效：当 RFC PR 已合并、且正在实施时。
  • 已落地：当 RFC 提议的更改在实际版本中发布时。
  • 已拒绝：当一个 RFC PR 在没有被合并的情况下被关闭。

活跃的征求意见列表

贡献者协议 (CLA)

为了接受你的拉取请求，我们需要你提交贡献者协议。如果你是第一次提交拉取请求，请告诉我们你已完成 贡献者协议签署。

点击此处签署你的贡献者协议

何时遵循此流程

如果你打算对 LCUI 或其文档进行“实质性”改动，则应考虑使用此过程。

构成“实质性”变化的内容是根据社区规范不断演变的，但可能包括以下内容：

  • 基于新 API 接口实现的新功能
  • 删除已作为发布渠道的一部分提供的功能
  • 引入新的惯用用法或约定，即使它们不包括对 LCUI 本身的代码更改

一些更改不需要征求意见：

  • 改写、重组或重构
  • 添加或删除警告
  • 添加的内容只会被其他 LCUI 实现者注意到，而对 LCUI 用户是不可见的

为什么你需要这样做

为了提升稳定性，更多地考虑我们所做的每一项更改对最终用户可能造成的影响，另一方面，也需要防止新 API 变得更复杂。

在 LCUI 的 2.x 版本之前，所有改动都没有文档，其中有些改动并没有经过认真思考和设计，在后期维护时，它们会阻碍我们理解相关需求和设计意图。对于用户而言，我们希望公开 LCUI 已实施的和待实施的改动，以征求更好的改进意见，让新增的改动内容更稳定可靠，而不是像以前那样随便增加了一些没有文档的功能，然后又随便删掉，又或是推倒重写。

此外，在对 LCUI 进行更改时，RFC 流程可以引导你完成我们的思考过程，这样我们就可以在讨论为什么或为什么不应该进行这些更改时达成共识。

在提交前收集反馈

在深入研究 RFC 所需的 API 设计细节级别之前，获得对你的概念的反馈通常很有帮助。你可以在此仓库上提出问题以展开讨论，目标是最终制定具有特定实现设计的 RFC 拉取请求。

流程是什么

简而言之，要将主要功能添加到 LCUI，首先必须将 RFC 作为 markdown 文件合并到此代码库中。届时 RFC 的状态是“已确认”并且可能以最终包含到 LCUI 中为目标来实现。

  1. 基于此代码库中的模板 (0000-template.zh-cn.md) ，在新的 Markdown 文件中撰写你的提案。
    • 注意细节：RFC 没有提供令人信服的动机，没有展示对设计影响的理解，或者对缺点或替代方案不诚实，往往不会被接受。
  2. 在讨论板块中打开一个新主题帖，并确保将类别设置为“RFC Discussions”。
    • 在讨论主题帖中建立共识并整合反馈。 获得广泛支持的 RFC 比那些没有收到任何评论的 RFC 更有可能取得进展。
  3. 如果提案收到社区成员的极大兴趣和普遍积极的反馈，你可以准备一个 拉取请求：
    • Fork 此仓库。
    • 创建你的提案并命名为 active-rfcs/0000-my-feature.md (其中的 "my-feature" 对提案的描述，而编号无需指定)。
    • 提交拉取请求。确保它链接到讨论帖。
  4. 最终，核心团队将确定是否纳入 LCUI 中的候选 RFC。
    • RFC 可根据核心团队和社区的反馈进行修改。重大修改可能会触发新的最终评论期。
    • RFC 在公众讨论已经解决并且评论总结了拒绝的理由之后可能会被拒绝。然后，核心团队的一名成员应该关闭 RFC 的相关拉取请求。
    • RFC 可能会在其最终评论期结束时被接受。 核心团队成员将合并 RFC 的相关拉取请求，此时 RFC 将变为“已生效”状态。

有关活动 RFC 的详细信息

一旦 RFC 生效，作者就可以实现它并将该功能作为拉取请求提交到 LCUI 存储库。 变为“生效”意味着核心团队已经原则上同意并愿意合并它，并不意味着该功能最终会被合并。

此外，给定的 RFC 已被接受并处于“生效”状态这一事实并不意味着分配给其实现的优先级是什么，也不意味着当前是否有人正在处理它。

后续的 PR 可对生效的 RFC 进行修改。我们努力以反映功能最终设计的方式编写每个 RFC；但是这个过程的性质意味着我们不能期望每个合并的 RFC 都能实际反映下一个主要版本发布时的最终结果；因此，我们尝试按计划使每个 RFC 文档与语言功能保持同步，并通过对文档的后续拉取请求来跟踪此类更改。

实现 RFC

RFC 的作者没有义务实施它。 当然，欢迎 RFC 作者（像任何其他开发人员一样）在 RFC 被接受后发布实现以供审查。

一个生效的 RFC 应该有指向实现 PR 的链接（如果有的话）。 对实际实现的反馈应该在实现 PR 而不是原来的 RFC PR 中进行。

如果你对“活跃”RFC 的实现感兴趣，但无法确定其他人是否已经在处理它，请随时提问（例如，通过对相关问题发表评论）。

审查 RFC

核心团队的成员将尝试定期审查一些已打开的 RFC 拉取请求。 如果核心团队成员认为 RFC PR 已准备好接受进入生效状态，他们可以使用 GitHub/Gitee 的审查功能批准 PR，以表示他们批准了 RFC。

参考

LCUI 的 RFC 流程及文档内容参考自：