Soliciting feedback: Release cadence for out-of-tree features

SIGs such as the cloud providers operate like user-groups. The SIGs are responsible for tight integrations of provider APIs with Kubernetes APIs/Interfaces such as out-of-tree cloud provider interfaces, CSI, CNI, CRI specifications etc. These integrations satisfy a Kubernetes user's needs when running Kubernetes on a cloud provider (not necessarily motivated to enhance a specific implementation of Kubernetes such as EKS or AKS or GKE or VKE). These integrations contribute to the richness of the Kubernetes ecosystem and aim to drive consistent behavior through the interface implementation across providers. It is therefore in the best interest of the Kubernetes user that such implementations/integrations be pegged to a Kubernetes major version release and the testing, documentation discipline enforced on the in-tree Kubernetes features be adopted/recommended for the out-of-tree feature releases as well.

This leads to a couple of open questions that need to be resolved/discussed since no reference able guidelines exists today. Referring specifically to this [issue](https://github.com/kubernetes/sig-release/pull/386) in v1.13

1. Tracking out-of-tree Kubernetes features - should this be out of scope for the SIG-release team and in scope for the responsible SIG?

2. Cadence of out-of-tree feature releases - should SIGs continue to adhere to release best practices that Kubernetes in-tree features follow aka follow the requirements necessary with testing and documentation to move the feature from alpha to beta to GA?

3. Reporting out-of-tree feature updates - should a summary for out-of-tree features continue to be added to the Major Theme section of the release notes as described [here](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.13/release-notes-draft.md)

4. Publishing test results in testgrid - should the integration test results be post-submit, non-blocking and be visible in testgrid for an out-of-tree feature to qualify as beta/GA?

5. Documentation - should the documentation be regularly updated for a feature to move through the release cadence?

6. KEPs - should KEPs be necessarily updated for a feature to move through the release cadence?

7. Release cadence ownership - should the SIG Chairs be responsible for the quality of the releases and the systematic follow through on the release cadence?

Start by reviewing the linked sig-release/pull/386 discussion and release-1.13/release-notes-draft.md. Assess the seven open questions about ownership, cadence, testing, reporting, documentation, and KEPs; done means the SIG has recorded agreed guidelines or decisions for out-of-tree features.

Written by the indexing model from the issue text.