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.
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 and wiki in the main Enarx repo.
In the future, you will be able to browse the RFC Index 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 folder)
- RFCs that explain concepts underpinning many features (in the concepts folder)
RFCs go through a standard lifecycle.
To propose an RFC, use these instructions to raise a PR (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 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.
To get an RFC accepted, build consensus for your RFC on our chat 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.
To get an RFC adopted, socialise and implement it. 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.
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.
See notes about this in Contributing.
This repository is licensed under an Apache 2.0 License.
For more instructions about contributing, see Contributing.
The structure and a lot of the initial language of this repository was borrowed from the Hyperledger Aries RFCs, which borrowed it from Rust RFC. 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.