RFC process and template

Heavily adapted from the Rust RFC process. Thank you for the precedent!

Source: https://github.com/rust-lang/rfcs
Revision: 845d609e0025d07c8cb0ca017d942bdbe9a18484
License: MIT OR Apache-2.0

0000-template.md

@@ -0,0 +1,112 @@
+- Feature Name: (fill me in with a unique ident, `my_awesome_feature`)
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: [zkcrypto/rfcs#0000](https://github.com/zkcrypto/rfcs/pull/0000)
+- Tracking Issue: [zkcrypto/rfcs#0000](https://github.com/zkcrypto/rfcs/issues/0000)
+
+# 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 it was already included in the relevant crates and
+you were teaching it to another zkcrypto ecosystem developer. That generally
+means:
+
+- Introducing new named concepts.
+- Explaining the feature largely in terms of examples.
+- Explaining how zkcrypto ecosystem developers should *think* about the feature,
+  and how it should impact the way they use the crates. It should explain the
+  impact as concretely as possible.
+- If applicable, provide migration guidance.
+- If applicable, describe the differences between teaching this to existing
+  zkcrypto ecosystem developers and new zkcrypto ecosystem developers.
+- Discuss how this impacts the ability to read, understand, and maintain zkcrypto
+  ecosystem code. Code is read and modified far more often than written; will the
+  proposed feature make code easier to maintain?
+
+# 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?
+- Does the proposed change make zkcrypto ecosystem code easier or harder to
+  read, understand, and maintain?
+
+# 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 crate ecosystems and what experience have
+  their community had?
+- Papers: 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.
+
+This section is intended to encourage you as an author to think about the
+lessons from other crates, 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 from other crates.
+
+Note that while precedent set by other crates is some motivation, it does not on
+its own motivate an RFC. Please also take into consideration that zkcrypto
+sometimes intentionally diverges from common crate features.
+
+# 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 publication in a crate release?
+- 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 zkcrypto ecosystem as a whole in a holistic way. Try
+to use this section as a tool to more fully consider all possible interactions
+with the ecosystem in your proposal. Also consider how this all fits into the
+roadmap for the relevant crates.
+
+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.