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