Add an explanation regarding our release cadence (#216)

* Add an explanation regarding our release cadence

This commit sets expectations for when consumers can expect releases
during the formative stages of the project. It also lays out a way for
consumers to track where a release is at.

As a squad we need to properly tag each github issue with the proper
milestone.

Author: f5yacobucci

docs/release-process.md

@@ -1,9 +1,27 @@
-# Release Process for NGINX Kubernetes Gateway
+# Releases
 
 NGINX Kubernetes Gateway uses semantic versioning for its releases. For more information see https://semver.org.
 
 Warning: Major version zero (0.y.z) is reserved for development, anything MAY change at any time. The public API is not stable.
 
+NGINX Kubernetes Gateway, especially in its early stages, will release periodically on a feature set cadence. By feature set, we intend to mean 2-4 features as tracked by the repository's Github milestones. We do this to remain agile and to expose features relatively quickly, but also to minimize the cost of many frequent releases and the associated process overhead.
+
+This means users can expect a release generally every 1 or 2 months, and can also track the progress of a release and its features by viewing our Github milestones. Each issue scheduled for a release will be labelled with "enhancement" (initial feature requests are "proposals", the label "enhancement" will be exchanged when work is committed) and added to the milestone release, milestones will use the form vMAJOR.MINOR.PATCH. Multiple issues may be written to describe one use-case and each will be organized according to this process. Sub-issues should also link to their parent (the parent issue will list the links via mention notifications).
+
+Bugs and other issue types will use a similar format; once committed to a release they will be assigned to the milestone representing that release.
+
+When all milestone work is complete, we will begin our release process and publish artifacts accordingly.
+
+Example workflow (see issue process section for more detail [TBD]):
+
+1. Discuss open features when planning.
+
+1. Agree and commit to work.
+
+1. Add features to next milestone, for example, v0.2.0.
+
+1. Feature "proposal" label removed and "enhancement" label added.
+
 ### Steps to create a release.
 
 1. Create a release branch from main, use the naming format: release-MAJOR.MINOR.