88 lines
3.3 KiB
Markdown
88 lines
3.3 KiB
Markdown
---
|
|
name: RFC template
|
|
about: request for comments
|
|
title: "[RFC]"
|
|
labels: 'RFC'
|
|
assignees: ''
|
|
|
|
---
|
|
|
|
<!--- Provide a general summary of the RFC in the Title above -->
|
|
- Feature Name: (fill me in with a unique ident, `my_awesome_feature`)
|
|
- Start Date: (fill me in with today's date, YYYY-MM-DD)
|
|
|
|
# Summary
|
|
[summary]: #summary
|
|
|
|
One paragraph explanation of the feature.
|
|
|
|
# Motivation
|
|
[motivation]: #motivation
|
|
|
|
Why are we doing this? What use cases does it support? What is the expected outcome?
|
|
|
|
# Guide-level explanation
|
|
[guide-level-explanation]: #guide-level-explanation
|
|
|
|
Explain the proposal as if it was already included in the Occlum and you were teaching it to another Occlum user. That generally means:
|
|
|
|
- Introducing new named concepts.
|
|
- Explaining the feature largely in terms of examples.
|
|
- If applicable, provide sample error messages, deprecation warnings, or migration guidance.
|
|
- If applicable, describe the differences between teaching this to existing Occlum users and new Occlum users.
|
|
|
|
# Reference-level explanation
|
|
[reference-level-explanation]: #reference-level-explanation
|
|
|
|
This is the technical portion of the RFC. Explain the design in sufficient detail that:
|
|
|
|
- Its interaction with other features is clear.
|
|
- It is reasonably clear how the feature would be implemented.
|
|
- Corner cases are dissected by example.
|
|
|
|
The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
|
|
|
|
# Drawbacks
|
|
[drawbacks]: #drawbacks
|
|
|
|
Why should we *not* do this?
|
|
|
|
# Rationale and alternatives
|
|
[rationale-and-alternatives]: #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
|
|
[prior-art]: #prior-art
|
|
|
|
Discuss prior art, both the good and the bad, in relation to this proposal.
|
|
|
|
# Unresolved questions
|
|
[unresolved-questions]: #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 stabilization?
|
|
- 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?
|
|
|
|
# Future possibilities
|
|
[future-possibilities]: #future-possibilities
|
|
|
|
Think about what the natural extension and evolution of your proposal would
|
|
be and how it would affect the Occlum as a whole in a holistic way. Try to
|
|
use this section as a tool to more fully consider all possible interactions
|
|
with the project in your proposal. Also consider how this all fits into the
|
|
roadmap for the project and of the relevant sub-team.
|
|
|
|
This is also a good place to "dump ideas", if they are out of scope for the
|
|
RFC you are writing but otherwise related.
|
|
|
|
If you have tried and cannot think of any future possibilities,
|
|
you may simply state that you cannot think of anything.
|
|
|
|
Note that having something written down in the future-possibilities section
|
|
is not a reason to accept the current or a future RFC; such notes should be
|
|
in the section on motivation or rationale in this or subsequent RFCs.
|
|
The section merely provides additional information.
|