First version of an RFC process, based on Aries and Rust

This modifies/adds four files:
- README, which contains the general description of the RFC process
- contributing, which explains the process more pragmatically
- a template, for submitters to fill
- a picture, describing the process and used in the README

0000-template.md

@@ -0,0 +1,101 @@
+# Title (Ex. 0000: RFC Topic)
+- Authors: [your name](you@github-email) -- email is optional
+- Status: [PROPOSED](/README.md#proposed)
+- Since: 2019-12-26 (date you submit your PR)
+- Status Note: (explanation of current status)  
+- Supersedes: (link to anything this RFC supersedes)
+- Start Date: 2018-12-26 (date you started working on this idea)
+- Tags: feature, protocol
+
+## Summary
+
+One paragraph explanation of the feature.
+
+## Motivation
+
+Why are we doing this? What use cases does it support? What is the expected
+outcome?
+
+## Tutorial
+
+Explain the proposal as if it were already implemented and you
+were teaching it to another Enarx contributor or user. That generally
+means:
+
+- Introducing new named concepts.
+- Explaining the feature largely in terms of examples.
+- Explaining how Enarx contributors and/or users should *think* about the
+feature, and how it should impact the way they would use Enarx.
+- If applicable, provide sample error messages, deprecation warnings, or
+migration guidance.
+
+Some RFCs may be more aimed at contributors (e.g. for
+consensus internals); others may be more aimed at users.
+
+## Reference
+
+Provide guidance for implementers, procedures to inform testing,
+interface definitions, formal function prototypes, error codes,
+diagrams, and other technical details that might be looked up.
+Strive to guarantee that:
+
+- Interactions with other features are clear.
+- Implementation trajectory is well defined.
+- Corner cases are dissected by example.
+
+## Drawbacks
+
+Why should we *not* do this?
+
+## 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
+
+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 TEE-based systems and what experience have
+their community had?
+- For other teams: What lessons can we learn from other attempts?
+- 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 implementers, provide readers of your proposal 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 they are an adaptation
+from other communities.
+
+Note that while precedent set by other communities is some motivation, it
+does not on its own motivate an RFC here.
+
+## 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 
+proposal that could be addressed in the future independently of the
+solution that comes out of this doc?
+
+## Implementations
+
+If your proposal is related to code and you have a early implementation,
+mention it here and link to it.
+
+## 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. 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.

README.md

@@ -1,2 +1,92 @@
-# RFCs
-Holds RFCS (“Request for Comments”), proposals to improve Enarx
+# RFCs for Enarx
+
+This repo holds Request for Comments (RFCs), enhancement proposals to improve
+the Enarx project.
+
+Many changes, including bug fixes and documentation improvements can be
+implemented and reviewed via the
+[normal GitHub pull request workflow](https://github.com/enarx/enarx/wiki/How-to-contribute).
+
+Some changes though are "substantial", and we ask that these be put through a
+bit of a design process and produce a consensus among the community and
+the [sub-team]s.
+
+If you are here to learn about Enarx, as the code is still young, we
+recommend you look at the [code][https://github.com/enarx/enarx/) and
+[wiki](https://github.com/enarx/enarx/wiki) in the
+[main Enarx repo](https://github.com/enarx/enarx/).
+
+In the future, you will be able to browse [the RFC Index](index.md) for
+a current listing of all RFCs and their statuses.
+
+There are 2 types of Enarx RFCs:
+
+* RFCs that describe individual features (in the [features](./features) folder)
+* RFCs that explain concepts underpinning many features
+(in the [concepts](./concepts) folder)
+
+## RFC Lifecycle
+
+RFCs go through a standard lifecycle.
+
+![lifecycle](lifecycle.png)
+
+#### PROPOSED
+To __propose__ an RFC, [use these instructions to raise a PR](
+contributing.md#how-to-propose-an-RFC) (Pull Request) against the repo.
+Proposed RFCs are considered a "work in progress", even after they are merged.
+In other words, they haven't been endorsed by the community yet, but they
+seem like reasonable ideas worth exploring.
+
+#### DEMONSTRATED
+__Demonstrated__ RFCs have one or more implementations available, listed in
+the "Implementations" section of the RFC document. As with the PROPOSED status,
+demonstrated RFCs haven't been endorsed by the community, but the ideas put
+forth have been more thoroughly explored through the implementation(s).
+The demonstrated status is an __optional__ step in the lifecycle.
+
+#### ACCEPTED
+To get an RFC __accepted__, [build consensus](contributing.md#how-to-get-an-RFC-accepted)
+for your RFC on [chat](https://gitter.im/enarx/community) and in community
+meetings. If your RFC is a feature that's code-related, it MUST have
+reasonable tests. An accepted RFC is incubating on a standards track;
+the community has decided to polish it and is exploring or pursuing implementation.
+
+#### ADOPTED
+To get an RFC __adopted__, [socialize and implement](contributing.md#how-to-get-an-rfc-adopted).
+An RFC gets this status once it has significant momentum: the mental model
+it advocates has begun to permeate our discourse and the Enarx code is a
+representation of that. In other words, adoption is acknowledgment of 
+ _de facto_ standard.
+
+To __refine__ an RFC, propose changes to it through additional PRs.
+Typically these changes are driven by experience that accumulates during or
+after adoption. Minor refinements that just improve clarity can happen inline
+with lightweight review. Status is still ADOPTED.
+
+#### RETIRED
+An RFC is __retired__ when it is withdrawn from community consideration by
+its authors, when implementation seems permanently stalled, or when
+significant refinements require a superseding document. If a retired RFC has been
+superseded, its `Superseded By` field should contain a link to the newer spec,
+and the newer spec's `Supersedes` field should contain a link to the older spec.
+Permalinks are not broken.
+
+### Changing an RFC Status
+
+See notes about this in [Contributing](contributing.md#changing-an-rfc-status).
+
+## About
+
+#### License
+
+This repository is licensed under an [Apache 2 License](LICENSE). 
+
+For more instructions about contributing, see [Contributing](contributing.md).
+
+#### Acknowledgement
+
+The structure and a lot of the initial language of this repository was borrowed from the Hyperledger [Aries RFCs](
+https://github.com/hyperledger/aries-rfc), which borrowed it from [Rust RFC](https://github.com/rust-lang/rfcs).
+Their good work has made the setup of this repository much quicker and better than it otherwise would have been.
+Many thanks to both these communities.

contributing.md

@@ -0,0 +1,106 @@
+# Enarx RFCs
+
+## Contributing
+
+### Do you need an RFC?
+
+Use an RFC to advocate substantial changes to the Aries ecosystem, where
+those changes need to be understood by developers who *use* Aries. Minor
+changes are not RFC-worthy, and changes that are internal in nature,
+invisible to those consuming Aries, should be documented elsewhere.
+
+### Preparation
+
+Before writing an RFC, consider exploring the idea on the
+[chat](https://gitter.im/enarx/community), on a daily meeting call
+(see the [wiki page on contributing](
+https://github.com/enarx/enarx/wiki/How-to-contribute),
+Encouraging feedback from maintainers is a good sign that you're on
+the right track.
+
+### How to propose an RFC
+
+  - Fork [the RFC repo](https://github.com/enarx/rfc).
+  - Pick a descriptive folder name for your RFC. Don't pick a number yet.
+  - Decide which parent folder is appropriate for your RFC.
+    If it is about a specific protocol or decorator or feature, its parent
+    should be /features; if it is about a concept that will be used in many
+    different features, its parent should be /concepts.
+  - Create the folder and copy `0000-template.md` to `<parent>/<your folder name>/README.md`.
+  - Fill in the RFC. [Use MUST and SHOULD per standard conventions](https://tools.ietf.org/html/rfc2119). Put care into the details:
+    RFCs that do not present convincing motivation, demonstrate an understanding of the impact of the
+    design, or are disingenuous about the drawbacks or alternatives tend to be
+    poorly received. You can add supporting artifacts, such as diagrams and sample
+    data, in the RFC's folder.
+  - Consider how the RFC should be [tagged](/tags.md).
+  - Assign a number to your RFC. Get the number by inspecting open and closed PRs against
+    this repo to figure out what the next PR number will be). Rename your folder from
+    `<your folder name>` to `<your 4-digit number>-<your folder name>`. At the
+    top of your README.md, modify the title so it is in the form: `<your 4-digit
+    number>: Friendly Version of Your Title`. Commit your changes.
+  - Commit the updated version of /index.md and push your changes.
+  - Submit a pull request.
+
+Make sure that all of your commits conform to the license restrictions noted [below](#intellectual-rights).
+
+Enarx maintainers  will check to see if the process has been followed, and request
+any process changes before merging the PR.
+
+When the PR is merged, your RFC is now formally in the PROPOSED state.
+
+### Changing an RFC Status
+
+The lifecycle of an RFC is driven by the author or current champion of the RFC. To move an RFC along
+in the lifecycle, submit a PR with the following characteristics:
+
+- The PR should __ONLY__ change the RFC status.
+- The title of the PR should include a deadline date for merging the PR and the referenced RFC.
+  - Example: `Status to Accepted, deadline 2019.08.15, RFC 0095-basic-message`
+- The PR comment should document why the status is being changed.
+- The deadline date should be 2 weeks after announcing the proposed status change on an Enarx call. The PR should also be announced on the [chat](https://gitter.im/enarx/community).
+- Barring negative feedback from the community, the repo's maintainers should merge the PR after the deadline.
+- The deadline should be moved by two weeks after addressing each substantive change to the RFC made during the status change review period.
+
+
+### How to get an RFC demonstrated
+
+If your RFC is a feature, it's common (though not strictly required) for
+it to go to a DEMONSTRATED state next. Write some code that embodies the
+concepts in the RFC. Publish the code. Then [submit a PR](#changing-an-rfc-status) that adds your
+early implementation to the [Implementations section](/0000-template.md#implementations),
+and that changes the status to DEMONSTRATED. These PRs should be accepted
+immediately, as long as all tests pass.
+
+### How to get an RFC accepted
+
+After your RFC is merged and officially acquires the [PROPOSED status](
+README.md#status--proposed), the RFC will receive feedback from the larger community,
+and the author should be prepared to revise it. Updates may be made via pull request,
+and those changes will be merged as long as the process is followed.
+
+When you believe that the RFC is mature enough (feedback is somewhat resolved,
+consensus is emerging, and implementation against it makes sense), [submit a PR](#changing-an-rfc-status) that
+changes the status to [ACCEPTED](README.md#status--accepted). The status change PR
+will remain open until the maintainers agree on the status change.
+
+### How to get an RFC adopted
+
+An accepted RFC is a standards-track document. It becomes an acknowledged
+standard when there is evidence that the community is deriving meaningful
+value from it. So:
+
+- Implement the ideas, and find out who else is implementing.
+- Socialize the ideas. Use them in other RFCs and documentation.
+- Update the agent test suite to reflect the ideas.
+
+When you believe an RFC is a _de facto_ standard, [raise a PR](#changing-an-rfc-status) that changes the
+status to [ADOPTED](README.md#status--adopted).  If the community is friendly
+to the idea, the doc will enter a two-week "Final Comment Period" (FCP), after
+which there will be a vote on disposition.
+
+### Intellectual Rights
+
+This repository is licensed under an [Apache 2 License](LICENSE).
+This means that any contributions you make must be licensed in an Apache-2-compatible
+way, and must be free from patent encumbrances or additional terms and conditions. By
+raising a PR, you certify that this is the case for your contribution.