Guidance for skipping Alpha for feature gated changes

contributors/devel/sig-architecture/feature-gates.md

@@ -9,6 +9,17 @@ Feature gates are intended to cover the development life cycle of a feature - th
 Features generally progress through `Alpha` -> `Beta` -> `GA`. Sometimes we end up deciding that a feature is not going to be supported and we end up marking them as `Deprecated`.
 
 The majority of features will go through all three stages, but occasionally there are features which may skip stages.
+While some exceptions may happen, approvers should use the following guidance:
+- features that involve API changes must progress through all `Alpha`, `Beta`, `GA` stages
+- larger or more complex changes should progress through all `Alpha`, `Beta`, `GA` stages
+- smaller changes that carry non-trivial risk (e.g. due to changing user-facing behavior) might skip
+  `Alpha` and start directly in `Beta` (provided the appropriate `Beta` quality is achieved)
+  but should be off by-default until proven in some production environment
+- smaller changes with low enough risk might skip `Alpha` and start directly in `Beta`
+  (provided the appropriate `Beta` quality is achieved) and can be enabled by-default from the
+  very beginning
+- changes that are explicitly considered as bug fixes are recommended to go directly to `Beta`
+  and should be enabled by-default from the very beginning
 
 When we add a feature flag, we basically add if/else conditions to ensure that a feature is ONLY activated when either the default is on or if the deployer has switched it on explicitly. When a feature gate is disabled, the system should behave as if the feature doesn't exist. The only exception to this is [API input validation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) on updates, which should preserve and validate data if and only if it was present before the update (which could occur in case of a version rollback).