From ca53896189514eb9addbe7b53acad92f68b0c8fd Mon Sep 17 00:00:00 2001 From: Willem Pienaar Date: Thu, 20 Dec 2018 18:06:46 +0800 Subject: [PATCH] Added rfcs/ folder with readme and template --- rfcs/0000-template.md | 86 +++++++++++++++++++++++++++++++++++++++++++ rfcs/README.md | 42 +++++++++++++++++++++ 2 files changed, 128 insertions(+) create mode 100644 rfcs/0000-template.md create mode 100644 rfcs/README.md diff --git a/rfcs/0000-template.md b/rfcs/0000-template.md new file mode 100644 index 0000000000..cf9e06a726 --- /dev/null +++ b/rfcs/0000-template.md @@ -0,0 +1,86 @@ +- Feature Name: (fill me in with a unique ident, my_awesome_feature) +- Created Date: (fill me in with today's date, YYYY-MM-DD) +- RFC PR: (leave this empty) +- Feast Issue: (leave this empty) + +# Summary +[summary]: #summary + +One paragraph explanation of the feature. + +# Motivation +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +Explain the proposal as if the change was already included in Feast and you are teaching it to a Feast user. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Explain how users should think about the feature, and how it should impact the way they use Feast. Explain the impact as concretely as possible. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-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 +[prior-art]: #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 software(s) and what experience has their community had? +- For community proposals: Is this done by some other community and what were their experiences with it? +- For other teams: What lessons can we learn from what other communities have done here? + +This section is intended to encourage you as an author to think about the lessons from other projects, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation. + +# Unresolved questions +[unresolved-questions]: #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 +[future-possibilities]: #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. Try to use this section as a tool to more fully consider all possible +interactions with the project in your proposal. +Also consider how the this all fits into the roadmap for the project +and of the relevant sub-team. + +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. \ No newline at end of file diff --git a/rfcs/README.md b/rfcs/README.md new file mode 100644 index 0000000000..f5735e7a8a --- /dev/null +++ b/rfcs/README.md @@ -0,0 +1,42 @@ +# Feast RFCs + +[Feast RFCs]: #feast-rfcs + +Many changes, including bug fixes and documentation improvements can be +implemented and reviewed via the normal GitHub pull request workflow. +However, any substantial changes should be put through a design process and +produce a concensus. + +The "RFC" (request for comments) process is intended to provide a consistent +and controlled path for new features to enter the project. + +## What the process is +[What the process is]: #what-the-process-is + +In short, to get a major feature added to Feast, one must first get the RFC +merged into the RFC repository as a markdown file. At that point the RFC is +"active" and may be implemented with the goal of eventual inclusion into Feast. + + - Clone the `feast` repository. + - Copy `rfc/0000-template.md` to `rfc/0000-my-feature.md` (where "my-feature" is + descriptive. don't assign an RFC number yet). + - Fill in the RFC. Put care into the details: RFCs that do not present + convincing motivation, demonstrate understanding of the impact of the + design, or are disingenuous about the drawbacks or alternatives tend to be + poorly-received. + - Submit a pull request. As a pull request the RFC will receive design + feedback from the larger community, and the author should be prepared to + revise it in response. + - Build consensus and integrate feedback. RFCs that have broad support are + much more likely to make progress than those that don't receive any + comments. Feel free to reach out to the RFC assignee in particular to get + help identifying stakeholders and obstacles. + - The core team will discuss the RFC pull request, as much as possible in the + comment thread of the pull request itself. Offline discussion will be + summarized on the pull request comment thread. + - Once the consensus is reached, the approvers will merge in the pull request + after which the implementation phase begins. + +## Attribution + +This process and template is based on [Rust RFCs](https://github.com/rust-lang/rfcs). \ No newline at end of file