[WIP] Add guidance for reviewers about squashing commits

content/en/docs/contribute/review/for-approvers.md

@@ -222,4 +222,29 @@ https://github.com/kubernetes/kubernetes/issues.
 If this is a documentation issue, please re-open this issue.
 ```
 
+### Squashing
 
+Do we require PR owners to squash before the merge, or do merge folk sometimes help them out by using the GitHub squash feature when we merge PRs? (edited)
+
+If there are lots of commits, maybe a history of edits towards getting the PR right:
+
+- I strongly prefer a squash first
+- if the author doesn't know how, a maintainer can offer to squash it for them and update their fork with the result
+- if there is time pressure, we could get GitHub to do a squash instead via the label
+
+If there are two or three commits:
+- I will ask for a squash first if I am confident the PR author knows how to
+- If the author doesn't know how, it's OK to add the label and get Tide / GitHub to sort it out
+
+Except that:
+- If there are, say, three commits and the middle commit does something broken or unwise, and the last commit reverts it
+  - then this will create rebase/merge conflicts for other folks
+  - even though the "files" view in GitHub web looks OK, and the Netlify preview looks OK
+- a maintainer should intervene as they see fit to avoid that risk to other contributors
+
+If we're launching a localization or doing a release, and we're merging in a branch that's not from a fork:
+- never squash
+
+Additional resources:
+- [Kubernetes Contributors, "GitHub Workflow"](https://www.k8s.dev/docs/guide/github-workflow/)
+- [Opening a pull request](/docs/contribute/new-content/open-a-pr#squashing-commits)