From 4e68f6fe14fe6806398275dcf0de570dcb866ff2 Mon Sep 17 00:00:00 2001 From: Connor Tsui Date: Sun, 19 Jan 2025 14:12:51 -0500 Subject: [PATCH] add details to rfcs template --- docs/src/rfcs/0000-template.md | 74 +++++++++++++++++++++++++++++----- 1 file changed, 63 insertions(+), 11 deletions(-) diff --git a/docs/src/rfcs/0000-template.md b/docs/src/rfcs/0000-template.md index 778c1fb..32795ef 100644 --- a/docs/src/rfcs/0000-template.md +++ b/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.