Add alternative names section

keps/sig-apps/4368-support-managed-by-label-for-batch-jobs/README.md

@@ -49,6 +49,9 @@
 - [Alternatives](#alternatives)
   - [Reserved controller name value](#reserved-controller-name-value)
   - [Defaulting of the manage-by label for newly created jobs](#defaulting-of-the-manage-by-label-for-newly-created-jobs)
+  - [Alternative names (scopes)](#alternative-names-scopes)
+    - [Generic kubernetes.io/managed-by](#generic-kubernetesiomanaged-by)
+    - [Job-prefixed job.kubernetes.io/managed-by](#job-prefixed-jobkubernetesiomanaged-by)
   - [Alternative mechanisms to mirror the Job status](#alternative-mechanisms-to-mirror-the-job-status)
     - [mirrored-by label](#mirrored-by-label)
     - [.spec.controllerName](#speccontrollername)
@@ -980,6 +983,38 @@ Job controller for many releases before we can ensure that all the jobs have it.
 An additional case for jobs without the label does not increase the
 complexity significantly.
 
+### Alternative names (scopes)
+
+#### Generic kubernetes.io/managed-by
+
+The idea was suggested (see [thread](https://github.com/kubernetes/enhancements/pull/4370/files#r1433055461))
+that the similar mechanism might be useful for other k8s controllers.
+
+**Reasons for discarding/deferring**
+
+There is currently no clear use case to support the label across the stack for
+APIs like StatefulSets, Deployments, or DaemonSets.
+
+A generic name without support across all k8s APIs might be confusing to the
+users, and supporting it for all k8s APIs would be much bigger effort than
+currently needed for the MultiKueue scenario use.
+
+The "managed-by" label idea has significant risks, such as
+[ecosystem fragmentation due to forks](#ecosystem-fragmentation-due-to-forks).
+It makes sense to start with limited scope as a "pilot" and assess the impact.
+
+#### Job-prefixed job.kubernetes.io/managed-by
+
+The idea of job-prefixed label was suggested (see [here](https://github.com/kubernetes/enhancements/pull/4370/files#r1467153754)).
+
+**Reasons for discarding/deferring**
+
+We prefer the "batch" prefix for consistency with current labels used by the Job
+controller (see [here](https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/batch/types.go#L29-L46)).
+
+The "batch" prefix fits well for the use case of supporting this label
+in other batch Job CRDs supported by Kueue, such as JobSet, MPIJob, RayJob, etc.
+
 ### Alternative mechanisms to mirror the Job status
 
 A couple of other approaches to allow mirroring of the Job status was considered.