53 lines
2.1 KiB
Markdown
53 lines
2.1 KiB
Markdown
|
- 创建时间: (按照创建时间填写, 日-月-年)
|
|||
|
|
- RFC（请求评论） PR: [代码仓名称/rfc#pr number](https://gitee.com/openharmony/repositroy-name/pulls/xxxx)
|
|||
|
|
- Issue: [代码仓名称/issue number](https://gitee.com/openharmony/repository-name/issues/xxxxxx)
|
|||
|
|
|
|||
|
|
#（RFC 标题）
|
|||
|
|
|
|||
|
|
## 概括
|
|||
|
|
|
|||
|
|
> 提案的简要概述。
|
|||
|
|
|
|||
|
|
## 目的
|
|||
|
|
|
|||
|
|
> 为什么要这样设计和实施？支持了那些用户场景？预期的结果是什么？
|
|||
|
|
|
|||
|
|
## 设计细节
|
|||
|
|
|
|||
|
|
> 该章节包含 RFC的主要内容。
|
|||
|
|
|
|||
|
|
> 为大家详细阐述设计的思路：详细的背景和设计介绍更能有助于大家的理解，包括详细模块设计细节，以及如何使用模块指导，其中任何新的专业术语要有明确的定义。
|
|||
|
|
|
|||
|
|
## 缺点
|
|||
|
|
|
|||
|
|
> 为什么我们应该*不*这样做？请考虑关于此提案与现有方案和规划特性等的集成对用户的影响。
|
|||
|
|
|
|||
|
|
> 选择任何方案都需要权衡，请尝试在此描述相关的问题。
|
|||
|
|
|
|||
|
|
## 基本原理和替代方案
|
|||
|
|
|
|||
|
|
> 为什么这个设计在可选的设计方案中是最好的？
|
|||
|
|
|
|||
|
|
> 还考虑了哪些其他设计，不选择它们的理由是什么？
|
|||
|
|
|
|||
|
|
> 没有选择其他的设计方案会有什么影响？
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 现有技术
|
|||
|
|
|
|||
|
|
讨论与该提案相关的现有技术，无论是好的还是坏的。这可以包括的一些说明：
|
|||
|
|
|
|||
|
|
> 相同领域的中其他解决方案是如何解决这个问题。
|
|||
|
|
|
|||
|
|
> 是否有任何已发表的论文或重要的帖子讨论过这个问题？如果你有一些相关的论文可以参考，这可以作为更详细的理论背景。
|
|||
|
|
|
|||
|
|
本节旨在鼓励您作为提案者洞察其他平台的经验知识，为您的 RFC 阅读者提供更全面的了解。如果没有现有技术，无论它们是全新的还是从其他业务改造而产生，那说明您的想法很有创新性。
|
|||
|
|
|
|||
|
|
## 遗留问题
|
|||
|
|
|
|||
|
|
> 在合并之前，您希望通过 RFC 流程解决设计的哪些问题？
|
|||
|
|
|
|||
|
|
> 在功能稳定之前，您希望通过实施此功能解决设计的哪些问题？
|
|||
|
|
|
|||
|
|
> 您认为哪些相关问题超出了本 RFC 的范围，这些问题可以在未来独立于本 RFC 的解决方案解决？
|