Add details to rfcs template

docs/src/rfcs/0000-template.md

@@ -4,24 +4,76 @@
 - RFC PR: [cmu-db/optd#0000](https://github.com/cmu-db/optd/pull/0000)
 - Tracking Issue: [cmu-db/optd#0000](https://github.com/cmu-db/optd/issues/0000)
 
-## Summary
+# Summary
 
-## Motivation
+One paragraph explanation of the feature.
 
-## Non Goals (if relevant)
+# Motivation
 
-## Impacted components (e.g. core, memo table, representation, rule engine, etc.)
+Why are we doing this? What features would this add? What is the expected outcome?
 
-## Proposed implementation
+# Impacted components
 
-### Reliability, failure modes and corner cases (if relevant)
+Which components (e.g. core, memo table, representation, rule engine, etc.) will need to be changed
+or will be affected by this feature?
 
-### Scalability (if relevant)
+# Proposed implementation
 
-### Unresolved questions (if relevant)
+This section should focus on how this feature should be implemented, and the design decisions that
+need to be made in order to make the feature work.
 
-## Alternative implementation (if relevant)
+Explain the design in sufficient detail that:
 
-## Pros/cons of proposed approaches (if relevant)
+- Its interaction with other features is clear.
+- It is reasonably clear how the feature would be implemented.
+- Corner cases are dissected by example.
 
-## Definition of Done (if relevant)
+Include subsections on:
+
+- Enginering effort: How hard will it be to implement this feature?
+- Reliability: What failure modes and corner cases would this feature introduce?
+- Scalability: How scalable is this feature?
+
+# Drawbacks
+
+Why should we _not_ do this?
+
+# Rational and alternatives
+
+- 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?
+
+# Prior art
+
+Discuss prior art, both the good and the bad, in relation to this proposal.
+
+A few examples of what this can include are:
+
+- Does this feature exist in other optimizers and what experience did the people implementing that
+  feature have?
+- Are there any published papers or great posts that discuss this? If you have some relevant papers
+  to refer to, this can serve as a more detailed theoretical background.
+
+# Unresolved Questions
+
+- What parts of the design do you expect to resolve through the RFC process before this gets merged?
+- What parts of the design do you expect to resolve through the implementation of this feature
+  before stabilization?
+- What related issues do you consider out of scope for this RFC that could be addressed in the
+  future independently of the solution that comes out of this RFC?
+
+# Future possibilities
+
+Think about what the natural extension and evolution of your proposal would be and how it would
+affect the project as a whole in a holistic way.
+
+This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but
+otherwise related.
+
+If you have tried and cannot think of any future possibilities, you may simply state that you cannot
+think of anything.
+
+Note that having something written down in the future-possibilities section is not a reason to
+accept the current or a future RFC; such notes should be in the section on motivation or rationale
+in this or subsequent RFCs. The section merely provides additional information.