RFC: An RFC process #380
RFC: An RFC process #380
Conversation
An initial RFC for the RFC process itself Signed-off-by: Nathan Smith <[email protected]>
|
|
||
| ## The RFC process | ||
|
|
||
| To create an RFC, create a copy the RFC template to a new file |
There was a problem hiding this comment.
I'd suggest we start in a Google doc or hackmd actually, then move to a pull request toward the end.
GitHub PRs are unfortunately really bad for quick, small changes that would probably occur at the start of a design discussion.
The template can still get filled in and sent as a PR, but as a rule of thumb there probably shouldn't be many comments/revisions at that point otherwise the process becomes painful.
There was a problem hiding this comment.
So to make a concrete suggestion: To create an RFC, open an issue with a link to a google doc or hackmd. After general consensus has been reached, convert to markdown and open a PR in a new file.
You can of course just skip the google doc portion if you're feeling lucky :)
There was a problem hiding this comment.
Hmmm I just worry that the google docs / hackmd never really make it into the documented code base if that is where they start out. Buttt to be fair, I haven't really participated in this kind of open design work before so I don't know the short coming of Github versus other places to review. Happy to go with prior art or experience.
The really big thing for me is that we have a pattern for discussing and agreeing on the big work and then making those decisions documented and discoverable after
There was a problem hiding this comment.
Ah yeah, it's definitely a risk. It's better than not having them though. Starting in code review is pretty hard because small stuff like wordsmithing at the start tends to result in a million comments, and GitHub makes that kind of thing hard to track. With a doc, the reviewer can just fix typos or address small formatting things directly without needing to leave a comment for the author to do it.
Basically I see it as a pre-step, to build consensus and circulate ideas even earlier than getting to a PR/code review stage. Docs also have the benefit that they can have multiple authors, rather than it just being one person submitting a PR being responsible for making all the changes/edits.
But if you want to skip that step for a specific PR/RFC, then I guess you can always go for it!
There was a problem hiding this comment.
Yeah that totally makes sense! Better to have that first low-barrier idea out there and shared early in easy to collaborate format and open the PR once you're pretty set its a good idea. Ok, I'll write that into the process!
|
It might be good to fold (or link / reference) this into the work @haydentherapper kicked off 'maintainer friction' over in sigstore/community Overall I support this though, fulcio is expected to be pumping out what could be millions of certificates a day, so we need decent change control in place. I would really like to see the same on rekor as well. |
|
Going to close this one per @lukehinds suggestion. Maybe how this works could live in the community repo? Anyways I want to discuss and think about it so I won't leave this PR hanging like this. |
Summary
This is an RFC for the RFC process itself. I've documented a bit of background in #379 but to summarize:
The attached RFC describes what that process could look like
Ticket Link
Fixes #379
Release Note