fill Rollout, Upgrade and Rollback Planning

Author: chenk008

keps/sig-api-machinery/4346-informer-metrics/README.md

@@ -689,13 +689,17 @@ rollout. Similarly, consider large clusters and how enablement/disablement
 will rollout across nodes.
 -->
 
+Feature has no impact on rollout/rollback, and no impact on running workloads.
+
 ###### What specific metrics should inform a rollback?
 
 <!--
 What signals should users be paying attention to when the feature is young
 that might indicate a serious problem?
 -->
 
+The memory used by this metrics continues to grow, consuming a significant amount
+
 ###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
 
 <!--
@@ -704,12 +708,16 @@ Longer term, we may want to require automated upgrade/rollback tests, but we
 are missing a bunch of machinery and tooling and can't do that now.
 -->
 
+Not yet. In the alpha releases, we could test this.
+
 ###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
 
 <!--
 Even if applying deprecation policies, they may still surprise some users.
 -->
 
+This feature does not deprecate or remove any features/APIs/fields/flags/etc.
+
 ### Monitoring Requirements
 
 <!--