Add more details to encourage successful RFCs

0000-template.md

@@ -10,18 +10,56 @@
 
 ## Motivation
 
-> Why are we doing this? What use cases does it support? What is the expected
-outcome?
+> Why are we doing this? What use cases does it support?
+
+> Please provide specific examples. If you say "this would be more flexible" then
+> give an example of something that becomes easier. If you say "this would be make
+> it easier to do X" then give an example of what that looks like today and what's
+> hard about it.
+
+> Don't assume that others recognize the problem is one that needs to be solved
+> Is there some concrete issue you cannot accomplish without this?
+> What does it look like to accomplish some set of goals today and how could
+> that be improved?
+> Are there any workarounds that are necessary today?
+> Are there open issues on Github where people would be helped by this?
+> Will the change have performance impacts? Can you quantify them?
+
+> Please focus on explaining the motivation so that if this RFC is not accepted,
+> the motivation could be used to develop alternative solutions. In other words,
+> enumerate the constraints you are trying to solve without coupling them too
+> closely to the solution you have in mind.
 
 ## Detailed design
 
-> This is the bulk of the RFC.
+### Technical Background
 
-> 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.
+> There are a lot of ways Svelte is used. It's hosted on different platforms;
+> integrated with different libraries; built with different bundlers, etc. No one
+> person knows everything about all the ways Svelte is used. What does someone who
+> knows about Svelte but hasn't necessarily used anything outside of it need to
+> know? Are there docs you can share?
+
+> How do different libraries or frameworks implement this feature? We can take
+> design inspiration from others who have done this well and improve upon the
+> designs or make them better fit Svelte.
+
+### Implementation
+
+> Explain the design in enough detail for somebody familiar with the framework to
+understand, and for somebody familiar with the implementation to implement. Any
+> new terminology should be defined here.
+
+> Explain not just the final design, but also how you arrived at it. What
+> constraints did you face? Are there corner cases you've come up with solutions for?
+
+> Explain how your design fits into the larger picture. Are the other open problems
+> in this area you're familiar with? How does this design fit with potential
+> solutions for those issues?
+
+> Connect your design to the motivations you listed above. When describing a part of
+> the design, it can be useful to share an example of what it would look like to
+> utilize the implementation as solution to the problem.
 
 ## How we teach this
 
@@ -48,9 +86,9 @@ on the impact of the API churn on existing apps, etc.
 
 > 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.
+> This section could also include prior art, that is, how other frameworks in the
+> same domain have solved this problem differently.
 
 ## Unresolved questions
 
-> Optional, but suggested for first drafts. What parts of the design are still
-TBD?
+> Optional, but suggested for first drafts. What parts of the design are still TBD?

README.md

@@ -4,6 +4,8 @@ This is a place to discuss major changes to Svelte — where 'major' implies sig
 
 Most changes don't need to go through the RFC process and can rely on issues and pull requests.
 
+A huge part of the value on an RFC is defining the problem clearly, collecting use cases, showing how others have solved a problem, etc. Coming up with a design is very iterative and only one part of the process. An RFC can provide tremendous value without the design described in it being accepted.
+
 The is inspired by (which is to say shamelessly ripped off from) the RFC process adopted by [React](https://github.com/reactjs/rfcs), [Ember](https://github.com/emberjs/rfcs) and others. The process itself is subject to change (or even abandonment!) as we gain experience with it.
 
 
@@ -39,4 +41,4 @@ If you are interested in working on the implementation for an 'active' RFC, but
 
 ## Reviewing RFCs
 
-This is where we differ from other teams using this process — we don't have regular core team meetings, and tend to do all our thinking informally, in the open, when time allows.
+We tend to do our thinking informally, in the open, when time allows. There are a large number of community members relative to a small number of a core contributors who have many responsibilities. You can help ensure your RFC is reviewed in a timely manner by putting in the time to think through the various details discussed in the template. It doesn't scale to push the thinking onto a small number of core contributors. If reviewers raise an issue, don't dismiss it as irrelevant, but take the time to provide examples or data explaining it and coming up with ways that the design might be changed in response. Sometimes answering a single question can be very time consuming (such as setting up a benchmark), but discussions tend to stall out if concerns don't get thoroughly addressed.