[PROPOSAL] Remove Stage 4 from RFC process (#1194)

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.

Co-authored-by: Eric Beahan <eric.beahan@elastic.co>

rfcs/0000-rfc-template.md

@@ -16,15 +16,11 @@ Stage 0: Provide a high level summary of the premise of these changes. Briefly d
 ## Fields
 
 <!--
-Stage 1: Describe at a high level how this change affects fields. Which fieldsets will be impacted? How many fields overall? Are we primarily adding fields, removing fields, or changing existing fields? The goal here is to understand the fundamental technical implications and likely extent of these changes. ~2-5 sentences.
+Stage 1: Describe at a high level how this change affects fields. Include new or updated yml field definitions for all of the essential fields in this draft. While not exhaustive, the fields documented here should be comprehensive enough to deeply evaluate the technical considerations of this change. The goal here is to validate the technical details for all essential fields and to provide a basis for adding experimental field definitions to the schema. Use GitHub code blocks with yml syntax formatting.
 -->
 
 <!--
-Stage 2: Include new or updated yml field definitions for all of the essential fields in this draft. While not exhaustive, the fields documented here should be comprehensive enough to deeply evaluate the technical considerations of this change. The goal here is to validate the technical details for all essential fields and to provide a basis for adding experimental field definitions to the schema. Use GitHub code blocks with yml syntax formatting.
--->
-
-<!--
-Stage 3: Add or update all remaining field definitions. The list should now be exhaustive. The goal here is to validate the technical details of all remaining fields and to provide a basis for releasing these field definitions as beta in the schema. Use GitHub code blocks with yml syntax formatting.
+Stage 2: Add or update all remaining field definitions. The list should now be exhaustive. The goal here is to validate the technical details of all remaining fields and to provide a basis for releasing these field definitions as beta in the schema. Use GitHub code blocks with yml syntax formatting.
 -->
 
 ## Usage
@@ -68,17 +64,7 @@ Stage 2: Document new concerns or resolutions to previously listed concerns. It'
 -->
 
 <!--
-Stage 3: Document resolutions for all existing concerns. Any new concerns should be documented along with their resolution. The goal here is to eliminate the risk of churn and instability by resolving outstanding concerns.
--->
-
-<!--
-Stage 4: Document any new concerns and their resolution. The goal here is to eliminate risk of churn and instability by ensuring all concerns have been addressed.
--->
-
-## Real-world implementations
-
-<!--
-Stage 4: Identify at least one real-world, production-ready implementation that uses these updated field definitions. An example of this might be a GA feature in an Elastic application in Kibana.
+Stage 3: Document resolutions for all existing concerns. Any new concerns should be documented along with their resolution. The goal here is to eliminate risk of churn and instability by ensuring all concerns have been addressed.
 -->
 
 ## People

rfcs/README.md

@@ -26,15 +26,15 @@ It's important to understand the overall goals and intentions of the RFC process
 7. Open a PR to commit your proposed changes to the RFC and advance to stage 1
 8. ECS committee and/or team members review
 9. ECS committee and/or team member merges RFC, formally accepting the proposal
-10. Repeat steps 6-9 for stage 2, 3, and 4
+10. Repeat steps 6-9 for stages 2 and 3
 
 ## Using the RFC template
 
 All new RFCs should be started by copying [0000-rfc-template.md](./0000-rfc-template.md) with a name format of `0000-<dash-separated-name>.md`. When the first RFC stage is accepted, the ECS team will assign a unique RFC number, which will identify this RFC throughout all stages of the process.
 
 Throughout the RFC template are comments that provide guidance on what type of content to include in each stage. It's ideal if you remove comments from your RFC as you fill out the content and they become obsolete. A pristine, finished RFC will have no explanatory comments remaining.
 
-For the most part, content is additive as you move through the stages. Occasionally, advancing a stage will require modifying existing content. This is OK! This process should be iterative, and the RFC document is considered living until it is finished (i.e. accepted as stage 4).
+For the most part, content is additive as you move through the stages. Occasionally, advancing a stage will require modifying existing content. This is OK! This process should be iterative, and the RFC document is considered living until it is finished (i.e. accepted as stage 3).
 
 ## Skipping stages
 

stages.html

@@ -58,7 +58,7 @@ <h1>ECS Proposal Stages</h1>
   </tr>
   <tr>
     <td>1
-    <td>Proposal
+    <td>Draft
     <td>
       <ul>
         <li>Make the case for these changes
@@ -70,7 +70,7 @@ <h1>ECS Proposal Stages</h1>
       <ul>
         <li>Opened pull request for this proposal revising the existing strawperson
         <li>Identified "sponsor" at Elastic who will participate in RFC process and take ownership of the change after the process completes
-        <li>Types of fields or changes outlined
+        <li>Outlined initial field definitions
         <li>High-level description of examples of usage
         <li>High-level description of example sources of data
         <li>Identified potential concerns and implementation challenges/complexity
@@ -79,58 +79,41 @@ <h1>ECS Proposal Stages</h1>
       </ul>
     </td>
     <td>ECS team accepts the premise of the addition and commits to considering this proposal as it advances.
-    <td>None
+    <td>Draft field definitions can be committed to the ECS schema as "experimental" fields
     <td>Major
     <td>Proof of concepts, demos
   </tr>
   <tr>
     <td>2
-    <td>Draft
+    <td>Candidate
     <td>Identify a comprehensive set of field definitions that could be appropriate for real-world usage
     <td>
       <ul>
         <li>Opened pull request for this draft revising the existing proposal
-        <li>Outlined initial field definitions
+        <li>Completed field definitions
         <li>Included a real world example source document
         <li>Identifies scope of impact of changes to ingestion mechanisms (e.g. beats/logstash), usage mechanisms (e.g. Kibana applications, detections), and the ECS project (e.g. docs, tooling)
         <li>Subject matter experts weighed in on technical utility of field definitions in the pull request
       </ul>
     </td>
-    <td>The initial field definitions are a comprehensive, though not necessarily complete, model of the addition to the schema. Fundamental questions and concerns are resolved, though some less significant questions remain open.
-    <td>Draft field definitions can be committed to the ECS schema as "experimental" fields
+    <td>The initial field definitions comprehensively model the addition to the schema. Fundamental questions and concerns are resolved, though some less significant questions remain open.
+    <td>Candidate field definitions can be committed to the ECS schema as "beta" fields
     <td>Iterative
-    <td>Experimental and beta features
+    <td>Experimental features
   </tr>
   <tr>
     <td>3
-    <td>Candidate
-    <td>Indicate that direct experience from implementations and users is necessary to validate the additions
-    <td>
-      <ul>
-        <li>Opened pull request for this candidate revising the existing draft
-        <li>Completed field definitions
-        <li>Included multiple real world example source documents
-        <li>Existing or newly raised questions and concerns are addressed
-      </ul>
-    </td>
-    <td>There are no further open questions or unaddressed concerns, and the field definitions are complete based on the information and usage experience we have.
-    <td>Candidate field definitions can be committed to the ECS schema as "beta" fields
-    <td>Minimal: only those determined to be critical based on usage experience
-    <td>GA features
-  </tr>
-  <tr>
-    <td>4
     <td>Finished
     <td>Indicate that the addition is ready for GA release in ECS
     <td>
       <ul>
         <li>Opened pull request for this candidate revising the existing candidate
-        <li>At least one real-world, production-ready usage implementation exists for the field definitions
+        <li>Included multiple real world example source documents
         <li>Existing or newly raised questions and concerns are addressed
         <li>No objections from sponsor, ECS team, or subject matter experts
       </ul>
     </td>
-    <td>The field definitions are in use as defined in real-world, production-ready software without raising additional questions or concerns that need to be resolved. The changes are ready to be released as GA in ECS.
+    <td>There are no further open questions or unaddressed concerns, and the field definitions are complete based on the information and usage experience we have.
     <td>Field definitions can be committed to the ECS schema as "GA" fields
     <td>None outside major versions
     <td>Any