[PROPOSAL] Remove Stage 4 from RFC process

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