-
Notifications
You must be signed in to change notification settings - Fork 407
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This template was sourced from https://github.com/chrisabruce/templates
- Loading branch information
1 parent
f8c2fc3
commit 7fab4ea
Showing
1 changed file
with
93 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,93 @@ | ||
- Start Date: <!-- fill me in with today's date, YYYY-MM-DD --> | ||
- HIP PR: <!-- leave this empty --> | ||
- Tracking Issue: <!-- leave this empty --> | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
One paragraph explanation of the proposal. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
Why are we doing this? What use cases does it support? What problems does it | ||
solve? What is the expected outcome? | ||
|
||
# Stakeholders | ||
[stakeholders]: #stakeholders | ||
|
||
* Who is affected by this HIP? | ||
|
||
* How are we soliciting feedback on this HIP from these stakeholders? Note that | ||
they may not be watching the HIPs repository or even aren't directly active in | ||
the Rust Async Ecosystem working group. | ||
|
||
# Detailed Explanation | ||
[detailed-explanation]: #detailed-explanation | ||
|
||
- Introduce and explain new concepts. | ||
|
||
- It should be reasonably clear how the proposal would be implemented. | ||
|
||
- Provide representative examples that show how this proposal would be commonly | ||
used. | ||
|
||
- Corner cases should be dissected by example. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
- Why should we *not* do this? | ||
|
||
# Rationale and Alternatives | ||
[alternatives]: #rationale-and-alternatives | ||
|
||
This is your chance to discuss your proposal in the context of the whole design | ||
space. This is probably the most important section! | ||
|
||
- 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? | ||
|
||
# Unresolved Questions | ||
[unresolved]: #unresolved-questions | ||
|
||
- What parts of the design do you expect to resolve through the HIP process | ||
before this gets merged? | ||
|
||
- What parts of the design do you expect to resolve through the implementation | ||
of this feature? | ||
|
||
- What related issues do you consider out of scope for this HIP that could be | ||
addressed in the future independently of the solution that comes out of this | ||
HIP? | ||
|
||
# Deployment Impact | ||
[deployment-impact]: #deployment-impact | ||
|
||
Describe how this design will be deployed and any potential imapact it may have on | ||
current users of this project. | ||
|
||
- How will current users be impacted? | ||
|
||
- How will existing documentation/knowlegebase need to be supported? | ||
|
||
- Is this backwards compatible? | ||
|
||
- If not, what is the procedure to migrate? | ||
|
||
# Success Metrics | ||
[success-metrics]: #success-metrics | ||
|
||
What metrics can be used to measure the success of this design? | ||
|
||
- What should we measure to prove a performance increase? | ||
|
||
- What should we measure to prove an improvement in stability? | ||
|
||
- What should we measure to prove a reduction in complexity? | ||
|
||
- What should we measure to prove an acceptance of this by it's users? |