diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc
index 42460d556..c763884e4 100644
--- a/CONTRIBUTING.adoc
+++ b/CONTRIBUTING.adoc
@@ -77,17 +77,17 @@ project to which you’re trying to contribute but that you don’t maintain."_
 
 == Keeping your Local Code in Sync
 * As mentioned above, you should always work on topic branches (since 'main' is a moving target). However, you do want
-to always keep your own 'origin' main branch in synch with the 'upstream' main.
+to always keep your own 'origin' main branch in sync with the 'upstream' main.
 * Within your local working directory, you can sync up all remotes' branches with: `git fetch --all`
 * While on your own local main branch: `git pull upstream main` (which is the equivalent of fetching upstream/main
 and merging that into the branch you are in currently)
-* Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b GH-123`
+* Now that you're in sync, switch to the topic branch where you plan to work, e.g.: `git checkout -b GH-123`
 * When you get to a stopping point: `git commit`
-* If changes have occurred on the upstream/main while you were working you can synch again:
+* If changes have occurred on the upstream/main while you were working you can sync again:
 - Switch back to main: `git checkout main`
 - Then: `git pull upstream main`
 - Switch back to the topic branch: `git checkout GH-123` (no -b needed since the branch already exists)
-- Rebase the topic branch to minimize the distance between it and your recently synched main branch: `git rebase main`
+- Rebase the topic branch to minimize the distance between it and your recently synced main branch: `git rebase main`
 (Again, for more detail see https://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing]).
 * **Note** You cannot rebase if you have already pushed your branch to your remote because you'd be rewriting history
 (see **'The Perils of Rebasing'** in the article).