proposal: Guidelines for /contrib components

Create an initial proposal regarding the expectations we should have
around the components in /contrib as well as a deprecation plan for
unmaintained components.

Signed-off-by: Kimonas Sotirchos <[email protected]>

proposals/20220926-contrib-component-guidelines.md

@@ -0,0 +1,55 @@
+# Guidelines for /contrib Components
+
+**Authors**: Kimonas Sotirchos [email protected]
+
+The motivation behind this proposal is to fully document expectations and
+requirements that componetns under `/contrib` should satisfy. This will make it
+more clear how to use a component, how it integrates with Kubeflow, the problems
+it tries to solve as well as dependency versions.
+
+## Goals
+
+* Document requirements that components under `/contrib` should satisfy
+* Introduce a process for deprecating unmaintained components
+
+## Non-Goals
+
+* Get into the discussion of which components are considered "Kubeflow" components
+    * The assumption until now is that components under the Kubeflow GitHub Org live
+      under the `/apps` dir, and all others under `/contrib`
+* Provide a migration plan for components to move out from `/contrib`
+* Modify the [`example/kustomization.yaml`](https://github.com/kubeflow/manifests/blob/master/example/kustomization.yaml) with new components
+
+## Proposal
+
+### Component Requirements
+
+Components living under `/contrib` should satisfy some strict requirements to
+ensure they are always usable by end-users and contain complementary documentation.
+
+These are the following items that all components under `/contrib` should have:
+1. A `README.md` file that documents:
+    * The K8s version and KF component versions that the component needs
+    * Instructions on how someone can install the component in a Kubeflow cluster
+        * Since Kubeflow manifests have standardized on [Kustomize](https://kustomize.io/)
+          we expect all manifests to be a kustomize packages
+    * How to use the component as part of Kubeflow (examples)
+    * The problems it tries to solve and the value it brings
+2. An OWNERS file with at least 2 users
+
+At this point we don't want to provide too much of a strict structure for the
+README. Developers are free to expose any other information in the README that
+they find fit, as long as the above info is exposed.
+
+
+### Deprecation plan
+
+The two proposed criteria for deciding that a component should be deprecated are:
+1. The component can not be installed in the minimum K8s version supported by Kubeflow
+2. The manifests are not working as expected and result in undeployable Pods
+3. The documented examples do not work as expected
+
+If a component meets all the above criteria then it will initially be marked as
+UNMAINTAINED/OUT-OF-DATE, in the component's README. Then if a whole Kubeflow release
+cycle concludes and the component is still in UNMAINTAINED/OUT-OF-DATE phase and
+withouth any feedback from the OWNERS, it will be removed.