Skip to content
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

Update RFC Process #20105

Closed
rytaft opened this issue Nov 16, 2017 · 0 comments
Closed

Update RFC Process #20105

rytaft opened this issue Nov 16, 2017 · 0 comments
Assignees

Comments

@rytaft
Copy link
Collaborator

rytaft commented Nov 16, 2017

The Cockroach Labs RFC Process needs to be updated. Based on @knz's suggestion in PR #20009, I updated docs/RFCS/README.md to say:

...
Go through the PR review. This process can last anywhere from a couple of days to several weeks, depending on the complexity of the proposal. See How Complex is Your Project to determine whether your proposal is low, medium, or high complexity.

  • Low complexity projects: Authors can begin the final comment period (FCP) as soon as they receive one LGTM.
  • Medium complexity projects: The PR must remain open for at least one week, including the FCP, to allow collaborators sufficient time to review the RFC.
  • High complexity projects: The PR must remain open for at least two weeks, including the FCP, to allow collaborators sufficient time to review the RFC. The two-week timeframe gives those who are out of office for part of the review period a chance to join the discussion.

When the dust on the PR review has settled, and if there is consensus to proceed with the project, begin the final comment period (FCP) by (1) posting a comment on the PR and (2) posting an announcement on the persistent public communication channel du jour (https://forum.cockroachlabs.com/ at the time of this writing). The FCP should last a minimum of two working days to allow collaborators to voice any last-minute concerns.
...

However, I merged PR #20009 too quickly, because later @bdarnell added:

But here the particular RFC that motivated this discussion/change was not a "small" RFC by any mean.

This is the crux of the issue - I believed that this was a small RFC and it wasn't until comments started arriving in the FCP that we realized the additional subtleties involved. The problem is that a medium-sized project was misjudged to be a small, so adding a policy that medium-sized projects get at least a week of discussion time wouldn't change anything in #19577 (at least for my part).

We could try to address this by adding a more rigorous process for sizing a project, but I'm not sure there's a cure that's better than the disease (we had a quorum of founders in favor of moving quickly in this case). I still believe it's best to allow things to move quickly even if that means occasionally discovering problems later than to tie things up with a more burdensome review process.

RFCs for higher complexity projects must have at least a week of comments and a week of FCP (or alternatively, a minimum of 2 weeks cumulative discussion+FCP). Again in the interest of colleagues who take 2 weeks vacation OOO at a time.

This is excessive. We don't need to structure things so that everyone can comment on every RFC regardless of vacation schedules. On a case-by-case basis we may want to require a particular person's review on an RFC, which may mean waiting for that person to come back from vacation, but I don't think such a long minimum duration is a good idea.

For complex RFCs, weeks-long discussions will happen naturally. But when it's not happening on its own I don't think we need to force it by slowing down the process. (I'd rather see a policy like "large projects should have at least two designated reviewers" instead of something time-based)

Clearly there is a difference of opinion, so we need to agree on a policy and update docs/RFCS/README.md with the decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants