Added rfcs/ folder with readme and template

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.

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).