Determine community operator policy

We have a few operator PRs out right now - #141 and #152 immediately come to mind, that raise some questions.

What is the policy for our primary operator repository on the contents of this repository and what that implies as far as ownership and support? Is the `maintainer` listed in the operator.yaml the contact for issue reporting and PRs? Is the KUDO team? Someone else? What is allowed into the operators repo? What is not? What gets tested?

Helm has a large chart repo and not all charts are actively maintained. They're even moving to a more federated approach instead of having a single repository of all charts.

This policy needs to account for all operators, including ones that the KUDO team spend their time on.

Review the operator.yaml maintainer field and the referenced operator PRs #141 and #152 first. Compare the current repository contents with the primary operator repository and Helm’s chart-repository approach, then document agreed ownership, support, admission, and testing policies for all operators.

Written by the indexing model from the issue text.