Adding Release Cycle Documentation

CHANGELOG/1.1-TEAM.md

@@ -9,3 +9,4 @@
 | Gateway Client Certificate Verification | @arkodg |
 | Session Persistence and BackendLBPolicy | @gcs278, @ginayeh |
 | TLS Terminology Clarifications | @candita, @robscott |
+| Gateway API Maintainers | @robscott, @shaneutt, @youngnick |

mkdocs.yml

@@ -164,4 +164,5 @@ nav:
     - Developer Guide: contributing/devguide.md
     - Documentation Style Guide: contributing/style-guide.md
     - Enhancement Requests: contributing/enhancement-requests.md
+    - Release Cycle: contributing/release-cycle.md
     - Contributor Ladder: contributing/contributor-ladder.md

site-src/contributing/enhancement-requests.md

@@ -52,6 +52,13 @@ create an initial discussion first.
 [discussion]: https://github.com/kubernetes-sigs/gateway-api/discussions/new/choose
 [meetings]: /contributing/#meetings
 
+## When are Enhancements Accepted?
+
+Gateway API has a predictable release cycle that includes multiple phases. New
+enhancements are only considered in the early phases of that release cycle while
+the scope of a release is being determined. For more information, refer to our
+[release cycle documentation](/contributing/release-cycle).
+
 ## Why are Enhancements Tracked
 
 As the project evolves, it's important that the community understands how the

site-src/contributing/release-cycle.md

@@ -0,0 +1,104 @@
+# Release Cycle
+
+In Gateway API 1.2+, we will be following a more structured and predictable
+release cycle that is inspired by the [upstream Kubernetes release
+cycle](https://kubernetes.io/releases/release/).
+
+## Goals
+
+* Ensure a predictable release schedule that enables 2-3 releases a year
+* Minimize the amount of time required from upstream API approvers and make it
+  more predictable
+* Avoid last minute additions to the scope of a release
+* Prevent experimental channel from growing by requiring GEPs to leave or
+  graduate before new ones can be added
+* Ensure that SIG-Network TLs are in the loop throughout the process, and have a
+  meaningful opportunity to review changes before a release
+* Provide more advance notice to everyone (SIG-Network TLs, Docs Reviewers,
+  Implementations, etc)
+
+## Phases
+
+### 1. Scoping
+
+**Timeline:** 4-6 weeks
+
+In this phase, the Gateway API maintainers and community will be responsible
+for determining the set of features we want to include in the release. Although
+we can always lessen scope after this point, we will avoid expanding the scope
+of the release at a later point unless it is absolutely necessary (critical flaw
+in design, security issue, etc).
+
+A key guideline in this phase is that we want to avoid expanding the size of the
+Experimental release channel. That means that each new experimental feature
+should be accompanied by the graduation or removal of an enhancement that is
+already in the Experimental channel.
+
+Note that in many cases, this scoping work will require some initial work on
+GEPs to determine their viability before committing to including them in a
+release.
+
+### 2. GEP Iteration and Review
+
+**Timeline:** 5-7 weeks
+
+In this phase the Gateway API community will work to update GEPs and meet
+graduation criteria for each feature that has been deemed in scope for the
+release cycle. As we’re working on new features, we will bring these discussions
+to the broader SIG-Network meetings for feedback throughout our development
+process. If a GEP has not merged with the target status by the end of this
+phase, it will be pulled from the scope of the release.
+
+### 3. API Refinement and Documentation
+
+**Timeline:** 3-5 weeks
+
+This phase is entirely focused on translating the concepts defined in the GEP
+(previous phase) into both API specification and documentation. This offers one
+final chance for the Gateway API community to refine the details that have
+already been agreed to in the GEP, but any modifications at this stage should be
+minor. If either documentation or API Spec have not merged by the end of this
+phase, this enhancement will be pulled from the scope of the release.
+
+### 4. SIG-Network Review and Release Candidates
+
+**Timeline:** 2-4 weeks
+
+This phase officially begins with the review session scheduled with SIG-Network
+TLs several weeks earlier in phase 3. In that review session, Gateway API
+maintainers and SIG-Network TLs should reach an agreement on the following:
+
+1. Any blockers for an initial release candidate
+1. How much time, if any, SIG-Network TLs want to review any changes in this
+   release
+1. A time after which we can assume lazy consensus and move on with the final
+   release of the API
+
+In general, we expect each minor release to be preceded by two release
+candidates. These release candidates will enable implementations to test against
+our release, work out any bugs, and gather early feedback on the viability of
+the release.
+
+## Contributions Welcome in Each Phase
+
+The following table illustrates when different kinds of contributions will be
+welcome. There will be some exceptions to this, but it should be useful as an
+overall guideline:
+
+| | 1. Scope | 2. GEP | 3. API | 4. Review |
+| - | :-: | :-: | :-:| :-: |
+| New GEPs | ✅ | ❌ | ❌ | ❌ |
+| Major GEP Updates | ✅ | ✅ | ❌ | ❌ |
+| GEP Refinement | ✅ | ✅ | ✅ | ❌ |
+| API Spec Additions | ❌ | ❌ | ✅ | ❌ |
+| New Conformance Tests | ✅ | ✅ | ✅ | ❌ |
+| Bug Fixes | ✅ | ✅ | ✅ | ✅ |
+| Documentation | ✅ | ✅ | ✅ | ✅ |
+| Review | ✅ | ✅ | ✅ | ✅ |
+
+## Timeline
+
+Given the above, we expect each release to take 14-22 weeks (4-5 months). At
+least initially, Gateway API maintainers will set end dates for each phase as we
+are beginning the phase. In future releases, we may choose to set all dates for
+the release in advance.