New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: document RFC final comment period guidelines #10181
Conversation
LGTM |
Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion, some commit checks pending. docs/RFCS/README.md, line 22 at r1 (raw file):
s/de/du :) Comments from Reviewable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
and if there is consensus to proceed with the project, announce that | ||
the RFC is entering its Final Comment Period (FCP) using the method | ||
de jour (https://forum.cockroachlabs.com/ at the time of this | ||
writing). The FCP should last a minimum of two working days to allow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FCP should also be announced on the github PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, with a bit of a rewrite.
consensus to proceed after the FCP, change the `Status` field of the | ||
document to `in-progress`, update the `RFC PR` field, and merge the | ||
PR. If the project is rejected, either abandon the PR or merge it | ||
with a status of `rejected` (depending on whether the document and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth mentioning that accepted RFCs can hit snags during implementation that could have been caught during the RFC review process. This is undesirable and something we should try to avoid, but hard to eliminate completely unless we make the RFC process overly onerous. For example, what happens if an expert on part of the system is on an extended vacation when an RFC is being reviewed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would be the purpose of such a mention? In other words, what is the guidance being issued to the reader, when they encounter such a case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose would be to set expectations: an accepted RFC is not an immutable contract. We can back out of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, PTAL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions. docs/RFCS/README.md, line 22 at r1 (raw file):
|
Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions, some commit checks pending. Comments from Reviewable |
This change is