Cleanup

Author: nickschot

text/0000-route-manager-api.md

@@ -31,15 +31,10 @@ suite: Leave as is
 
 ## Summary
 
-> One paragraph explanation of the feature.
-
 Define a generic Route Manager concept that can be used to implement new Route base classes as a stepping stone towards a new router.
 
 ## Motivation
 
-> Why are we doing this? What use cases does it support? What is the expected
-outcome?
-
 The intent of this RFC is to implement a generic Route Manager concept so that we’re able to provide room for experimentation and migration to a new router solution. It aims to provide a well-defined interface between the Router and Route concepts. Well-defined in this case means both API and lifecycle.
 
 This will unlock the possibility of implementing new Route base classes while also making it easier to replace the current router.
@@ -51,24 +46,6 @@ This RFC is **not** intended to describe APIs that Ember app developers would ge
 
 ## 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) 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
-
 ### Route Manager basics
 
 The minimal API for a Route Manager consists of `capabilities`, `createRoute` and a `getDestroyable` method.
@@ -320,39 +297,19 @@ interface RouteManager {
 
 ## 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?
-
-> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc.
-
-Since this is not an Ember-user facing feature the guides don’t need adjustment. Documentation will live in the API docs.
+Since this is not an Ember app developer facing feature the guides don’t need adjustment. Documentation will live in the API docs.
 
 ## 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.
+TBD
 
 ## 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.
+TBD
 
 ## Unresolved questions
 
-> Optional, but suggested for first drafts. What parts of the design are still
-TBD?
+TBD
 
 ## Addenda