forked from emberjs/rfcs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
b645584
commit 5c0a987
Showing
1 changed file
with
57 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,57 @@ | ||
- Start Date: (fill me in with today's date, YYYY-MM-DD) | ||
- Relevant Team(s): (fill this in with the [team(s)](README.md#relevant-teams) to which this RFC applies) | ||
- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name) | ||
- Tracking: (leave this empty) | ||
|
||
# <RFC title> | ||
|
||
## Summary | ||
|
||
> One paragraph explanation of the feature. | ||
## Motivation | ||
|
||
> Why are we doing this? What use cases does it support? What is the expected | ||
outcome? | ||
|
||
## Detailed design | ||
|
||
> This is the bulk of the RFC. | ||
> Explain the design in enough detail for somebody | ||
familiar with the framework to understand, and for somebody familiar with the | ||
implementation to implement. This should get into specifics and corner-cases, | ||
and include examples of how the feature is used. Any new terminology should be | ||
defined here. | ||
|
||
## How we teach this | ||
|
||
> What names and terminology work best for these concepts and why? How is this | ||
idea best presented? As a continuation of existing Ember patterns, or as a | ||
wholly new one? | ||
|
||
> Would the acceptance of this proposal mean the Ember guides must be | ||
re-organized or altered? Does it change how Ember is taught to new users | ||
at any level? | ||
|
||
> How should this feature be introduced and taught to existing Ember | ||
users? | ||
|
||
## Drawbacks | ||
|
||
> Why should we *not* do this? Please consider the impact on teaching Ember, | ||
on the integration of this feature with other existing and planned features, | ||
on the impact of the API churn on existing apps, etc. | ||
|
||
> There are tradeoffs to choosing any path, please attempt to identify them here. | ||
## Alternatives | ||
|
||
> What other designs have been considered? What is the impact of not doing this? | ||
> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. | ||
## Unresolved questions | ||
|
||
> Optional, but suggested for first drafts. What parts of the design are still | ||
TBD? |