54 lines
2.3 KiB
Markdown
54 lines
2.3 KiB
Markdown
- Start Date: (fill me in with today's date, DD-MM-YYYY)
|
|
- RFC(request for comments) PR: [repository name/rfcs#pr number](https://gitee.com/openharmony/repositroy-name/pulls/xxxx)
|
|
- Issue: [repository name/issue number](https://gitee.com/openharmony/repository-name/issues/xxxxxx)
|
|
# (RFC title goes here)
|
|
|
|
## Summary
|
|
|
|
> One paragraph explanation of the change.
|
|
|
|
## Motivation
|
|
|
|
> Why are we doing this? What use scenario does it support? What is the expected outcome?
|
|
|
|
## Design Detail
|
|
|
|
> Explain the design in enough detail for somebody
|
|
familiar with the infrastructure to understand. This should get into specifics and corner-cases,
|
|
and include examples of how the service is used. Any new terminology should be
|
|
defined here.
|
|
|
|
## Drawbacks
|
|
|
|
> Why should we *not* do this? Please consider the impact on users,
|
|
on the integration of this change with other existing and planned features etc.
|
|
|
|
> There are tradeoffs to choosing any path, please attempt to identify them here.
|
|
|
|
## Rationale and Alternatives
|
|
|
|
> Why is this design the best in the space of possible designs?
|
|
|
|
> What other designs have been considered and what is the rationale for not choosing them?
|
|
|
|
> What is the impact of not doing this?
|
|
|
|
|
|
## Prior Art
|
|
|
|
Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:
|
|
|
|
> How other services / infrastructures in the same domain have solved this problem.
|
|
|
|
> Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
|
|
|
|
This section is intended to encourage you as an author to think about the lessons from other organisations, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting whether they are brand new or if it is an adaptation from other services.
|
|
|
|
## Unresolved questions
|
|
|
|
> What parts of the design do you expect to resolve through the RFC process before this gets merged?
|
|
|
|
> What parts of the design do you expect to resolve through the implementation of this feature before stabilisation?
|
|
|
|
> What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
|