[PROPOSAL] Remove Stage 4 from RFC process #1194
Conversation
We currently have 5 stages in the end to end lifecycle of an RFC. When I proposed these 5 stages, I hoped that after the final stage we would have reliable fields that we'd only need to make breaking changes to infrequently in major versions, if at all. Another goal of mine was to make it explicit what was necessary to move a proposed change from any one stage to the next, so that contributors has clear guidance on how to make non-trivial changes to ECS and reviewers had clear guidance on whether a change was ready to progress. From the last few months of observing the RFC process in action, we've seen a great deal of scrutiny happening in stage 1 and 2. In practice, so much is covered in those stages that stage 3 has essentially just been a gut check and rubber stamp on the details. We haven't done a stage 4 change yet, but I have no reason to believe it will be anything other than a second rubber stamp on those same highly-scrutinized details. In the meantime, stage 3 changes continue to have an aura of incompleteness about them. They're considered "beta" in the schema, but in order to advance to "GA" they must first be rolled out in GA features in the products. But once a change is implemented in the product, it would be considerably difficult to change it in a way that didn't break that product, so the likely response would be to accommodate the stage 3 schema changes anyway until the next major version. In essence, I think having a stage 4 has little practical upside, but it does have three consequences: 1. Makes stage 3 changes appear to be less reliable or stable than they are in practice to users 2. Gives ECS authors and reviewers a false sense that there are not profound BC considerations in practice for any stage 3 change 2. Increases time to bring highly-vetted, critical changes into the fold by many months at least I've opened this proposal as a pull request to the stages doc to allow for commenting on the details. In summary, these are the proposed changes: - Remove Stage 4 - Rename stages to Strawperson -> Draft -> Candidate -> Finished - Update BC expectations of Stage 3 to "None outside major versions" - Start experimental schema support after Stage 1 As a bonus, these proposed changes relinquish the use of the word "proposal" as the name of a specific stage, so we can now use that term to refer to an RFC in general without ambiguity. Because this "proposed changes" nonsense is awkward.
|
I support this idea. It certainly follows the amount of activity and thinking that goes into creating solid proposals as early as stage 1 and stage 2. To spell out one of the consequences of the removal of stage 4, here's the relationship between RFC stages and fields appearing in ECS. Before this proposal:
After this proposal:
Here's some additional tasks I see, related to this change:
These tasks could be handled separately from this specific PR. |
There was a problem hiding this comment.
++ to removing stage 4 from the RFC process.
Thanks, @webmat, for capturing those other changes! If the proposal is accepted, I'll take ownership of following up on each.
A couple of additional suggested changes:
- Move
Outlined initial field definitionsto Stage 1's consideration criteria. - Adjust the
Acceptance into this stagecolumn for the new stage 2. I think the level of expected completeness here should be similar to what we have today with stage 3, with completed field definitions and most questions/concerns resolved.
Co-authored-by: Eric Beahan <eric.beahan@elastic.co>
|
I pushed the updates to the RFC template and RFC readme. I think the last step here is updating the stage name in all committed RFCs, and adjusting any stage numbers based on a quick audit of current state of each RFC. To help avoid annoying merge conflicts, for any RFC that has an open stage PR, I propose we suggest the stage rename directly in that PR. Any impacted RFC that doesn't have an open PR can be handled in a separate PR. |
There was a problem hiding this comment.
I think the last step here is updating the stage name in all committed RFCs, and adjusting any stage numbers based on a quick audit of current state of each RFC. To help avoid annoying merge conflicts, for any RFC that has an open stage PR, I propose we suggest the stage rename directly in that PR. Any impacted RFC that doesn't have an open PR can be handled in a separate PR.
I agree with this approach for the existing RFCs.
These changes LGTM 👍
We currently have 5 stages in the end to end lifecycle of an RFC. When I proposed these 5 stages, I hoped that after the final stage we would have reliable fields that we'd only need to make breaking changes to infrequently in major versions, if at all. Another goal of mine was to make it explicit what was necessary to move a proposed change from any one stage to the next, so that contributors has clear guidance on how to make non-trivial changes to ECS and reviewers had clear guidance on whether a change was ready to progress.
From the last few months of observing the RFC process in action, we've seen a great deal of scrutiny happening in stage 1 and 2. In practice, so much is covered in those stages that stage 3 has essentially just been a gut check and rubber stamp on the details. We haven't done a stage 4 change yet, but I have no reason to believe it will be anything other than a second rubber stamp on those same highly-scrutinized details.
In the meantime, stage 3 changes continue to have an aura of incompleteness about them. They're considered "beta" in the schema, but in order to advance to "GA" they must first be rolled out in GA features in the products. But once a change is implemented in the product, it would be considerably difficult to change it in a way that didn't break that product, so the likely response would be to accommodate the stage 3 schema changes anyway until the next major version.
In essence, I think having a stage 4 has little practical upside, but it does have three consequences:
I've opened this proposal as a pull request to the stages doc to allow for commenting on the details. In summary, these are the proposed changes:
As a bonus, these proposed changes relinquish the use of the word "proposal" as the name of a specific stage, so we can now use that term to refer to an RFC in general without ambiguity. Because this "proposed changes" nonsense is awkward.