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

Includes multiple suggestions, corrections and improveents from members of the team.

This modifies/adds five files:
- README, which contains the general description of the RFC process
- contributing, which explains the process more pragmatically
- a template, for submitters to fill
- an index.md document, which will list the RFCs as they are published
- a picture, describing the process and used in the README

00000-template.md

@@ -0,0 +1,110 @@
+# Title (Ex. 00000: RFC Topic)
+- Authors: [your name](you@github-email) -- email is optional
+- Status: [PROPOSED](/README.md#proposed)
+- Since: 20YY-MM-DD (date you submit your PR)
+- Status Note: (explanation of current status)  
+- Supersedes: (link to anything this RFC supersedes)
+- Start Date: 20YY-MM-DD (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 consensus on 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 an 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-teams.
+
+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 our [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__, [socialise and implement it](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.0 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,121 @@
+# Enarx RFCs
+
+## Contributing
+
+### Do you need an RFC?
+
+Use an RFC to advocate substantial changes to the Enarx ecosystem, where
+those changes need to be understood by developers who *use* Enarx. Minor
+changes are not RFC-worthy.
+
+### 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
+
+  1. Fork [the RFC repo](https://github.com/enarx/rfcs).
+  2. Choose a descriptive name for your RFC. Don't pick a number yet.
+  3. Decide which parent folder is appropriate for your RFC: `/features` or 
+    `/concepts`.
+    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`.
+  4. Create a directory with the descriptive name you chose and copy
+    `00000-template.md` to `<parent>/<your descriptive RFC name>/README.md`.
+  5. Fill in the RFC (ie: fill README.md). [Use MUST and SHOULD per standard conventions](https://tools.ietf.org/html/rfc2119).
+    Please pay attention to 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.
+  6. When you are ready to publish your RFC, it is time to assign a number to
+    it. The RFC number will be the Github Pull Request number (with the the
+    necessary leading number of zeroes). To find this number, inspect open and
+    closed PRs in this repo to figure out what the next PR number will be.
+  7. Add the RFC number to your directory. Rename it from `<your descriptive RFC name>`
+    to `<your 5-digit number>-<your descriptive RFC name>`. Don't forget to
+    put the number at the top of your README.md: modify the title so it is in
+    the form `<your 5-digit number>: Friendly Version of Your Title`.  
+  8. Commit your changes.
+  9. Push your changes to your forked `rfcs` repo.
+  10. Submit a pull request from your forked repo to `enarx/rfcs`.
+
+A note on numbering: if need be, you can always create the PR to get the
+number and then modify your files to incorporate this number and push them
+again. Or just come talk to us. Don't let numbering get in the way of
+submitting an RFC.
+
+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](/00000-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.0 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.

index.md

@@ -0,0 +1,3 @@
+This is the index of Enarx RFCs.
+
+More to come.