---
url: /rfcs/0000-template.md
---

# 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.

> Please keep in mind any implications within the Ember ecosystem, such as:
>
> * Lint rules (ember-template-lint, eslint-plugin-ember, eslint-plugin-ember-data / eslint-plugin-warp-drive) that should be added, modified or removed
> * Features that are replaced or made obsolete by this feature and should eventually be deprecated
> * Ember Inspector and debuggability
> * Server-side Rendering
> * Ember Engines
> * The Addon Ecosystem
> * IDE Support
> * Blueprints that should be added or modified

## 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 patterns, or as a
> wholly new one?

> Would the acceptance of this proposal mean the WarpDrive guides must be
> re-organized or altered? Does it change how WarpDrive is taught to new users
> at any level?

> How should this feature be introduced and taught to existing WarpDrive
> users?

> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc.

## Drawbacks

> Why should we *not* do this? Please consider the impact on teaching WarpDrive,
> 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 or libraries in the same domain have solved this problem.

## Unresolved questions

> Optional, but suggested for first drafts. What parts of the design are still
> TBD?