Merge pull request #5664 from saintube/patch-4

Fix typo in KEP 4671

Author: k8s-ci-robot

keps/sig-scheduling/4671-gang-scheduling/README.md

@@ -281,8 +281,8 @@ spec:
 ```yaml
 apiVersion: v1
 kind: Pod
-name:
-  jobset-job-1-abc123
+metadata:
+  name: jobset-job-1-abc123
 spec:
   ...
   workload:
@@ -293,15 +293,15 @@ spec:
 
 ```
 
-We decided for this option because it is more succint and makes the role of a pod clear just
+We decided for this option because it is more succinct and makes the role of a pod clear just
 from inspecting the pod (and simple/efficient to group).
 We acknowledge the fact that this option may require additional minor changes in the controllers
 to adopt this pattern (e.g. for LeaderWorkerSet we will need to populate the pod template
 similarly that we currently populate the labels).
 
-The primary alternative we consider was to introduce the the `PodGroupSelector` on each `PodGroup`
+The primary alternative we consider was to introduce the `PodGroupSelector` on each `PodGroup`
 to identify pods belonging to it. However, with this pattern:
-- there are additional corner cases (e.g. a pod links to a workload but none of its PodGroups matching
+- there are additional corner cases (e.g. a pod links to a workload but none of its PodGroups match
   that pod)
 - for replicated gang, we can't use the full label selector, but rather support specifying only the
   label key, similar to `MatchLabelKeys` in pod affinity
@@ -438,7 +438,7 @@ For `Beta`, we want to also touch requirements (2) and (3) by extending the sche
 a new dedicated phase (tentatively called Workload). In that phase,
 kube-scheduler will be looking at all pods from a gang (part of `Workload`) and compute the placement
 for all of these pods in a single scheduling cycle. Those placements will be stored only in-memory and
-block the required resources from scheduling. Tentively we plan to use `NominatedNodeName` field for it.
+block the required resources from scheduling. Tentatively we plan to use `NominatedNodeName` field for it.
 After that, pods will go through regular pod-by-pod scheduling phases (including Filter and Score)
 with a nomination as a form of validation the proposed placement and execution of this placement decision.
 Therefore we expect the order of processing pods won't ever be important, but all-or-nothing nature of