RFC00000: First version of an RFC process, based on Aries and Rust #1
Conversation
axelsimon
added
documentation
axelsimon
requested review from
connorkuehl,
lkatalin,
mbestavros,
MikeCamel,
npmccallum and
steveej
There was a problem hiding this comment.
I think the template is useful and the write-up is very thorough and seemed pretty clear. The set of instructions about making a PR and choosing your numbering scheme, etc., is somewhat complex and might serve as a deterrent. Does the Rust RFC also use this same PR-based method? I haven't gone through that process, so if it's similar then this probably works as well.
contributing.md
Outdated
| - 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. |
There was a problem hiding this comment.
If anything, I think this is where people would get lost or do something incorrectly; wondering if there is any way to make this more streamlined / intuitive and not require so many instructions (although there may not be). At least we can always request changes on a PR.
There was a problem hiding this comment.
Related thought: is it feasible to have some type of CI tests for this whole process to make sure people did do it correctly?
There was a problem hiding this comment.
This feels too complex. How about modelling on the Rust template? https://github.com/rust-lang/rfcs/blob/master/0000-template.md
There was a problem hiding this comment.
contributing.md is supposed to be the file that helps you fill in the template file (0000-template.md). Rust doesn't use it though, only Aries, but it does feel too complex, i agree.
I've tried to simplify it and make it a numbered list that is easy to follow and will actually help people fill the template.
There was a problem hiding this comment.
- Replace stray and forlorn instances of "Aries" with "Enarx"
- Change link to point to the updated repo link (https://github.com/enarx/RFCs)
axelsimon
force-pushed
the
RFC_template
branch
from
ec6986a to
69a130c
Compare
axelsimon
force-pushed
the
RFC_template
branch
from
69a130c to
98781cf
Compare
There was a problem hiding this comment.
Mostly grammatical nitpicks from me. Otherwise, this process makes a lot of sense. The structure the template provides will be super helpful for fleshing out a detailed proposal -- I find that's often something that holds me up.
If anything, I think I'll echo the sentiments I've heard saying it's important to ensure the PR process isn't too cumbersome. That should not be something that takes a whole lot of time.
Perhaps something we could consider for the RFC number is just using the PR number assigned by Github (ex. this one would be 00001, since it's PR #1 on the repo.)
I will defer approval to others, but I think this is a good start.
axelsimon
force-pushed
the
RFC_template
branch
from
98781cf to
3f2b620
Compare
|
I've incorporated all suggested changes and pushed a new version of the PR. Many thanks to all of you for taking the time to read through these documents as carefully as you did and making suggestions and corrections, it's really nice to see everyone getting behind this RFC process :) |
|
@connorkuehl, @mbestavros you were the last to have requested changes or made comments in that general direction. Does everything look good to you? I'd like to merge this if so :) |
|
Pinging @npmccallum too as he expressed a strong interest in checking this PR out. |
axelsimon
requested review from
npmccallum
and removed request for
npmccallum
There was a problem hiding this comment.
This is all very good. Thank you to everyone who contributed. In fact, I'm pleased to see so many directly involved.
I particularly liked @mbestavros's idea of using the PR# for the RFC number. This guarantees both uniqueness and numeric increase. It also means that we can write a test to validate the correct RFC number to prevent human error. Therefore, this is the only change I'd like to see adopted at this point.
|
Funny you should mention that as i was at a matrix meetup yesterday and as i realised that their MSC (matrix spec changes) process uses this same system, and thought we should do the same. |
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
axelsimon
force-pushed
the
RFC_template
branch
from
3f2b620 to
9caea26
Compare
axelsimon
changed the title
This modifies/adds four files:
This process is heavily taken from Hyperledger Aries and the Rust language (leaning more towards Aries, which is itself based on the Rust process), but adapted to our needs and the current level of maturity of Enarx.
I expect this to create some discussion, so please do comment and suggest changes.
My main fear is that this is too involved a process.