Fix typos in CONTRIBUTING.md (#1375)

CONTRIBUTING.md

@@ -54,11 +54,11 @@ To make sure your pull request is as easy to review as possible:
 
 * **Follow the style guide.** Please see the [KJ style guide](https://github.com/capnproto/capnproto/blob/master/style-guide.md) and the [tour of KJ](https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md) to understand how we write code.
 
-* **Split PRs into small commits wherever possible**, especially when it helps the reviewers separate concerns. The code should compile and all tests should pass at every commit. For example, if you are adding a fetaure that requires refactoring some code, do the refactoring in a separate commit (or series of commits) from introducing the new feature. Each commit message should describe the particular bit of refactoring in the commit and why it was needed. It's especially important to use separate commits when moving and modifying code. If you need to move a large block of code from one place to another, try your best to do it in an individual commit that is purely a block cut/paste without making any modifications to the code. Then, actually modify the code in the next commit.
+* **Split PRs into small commits wherever possible**, especially when it helps the reviewers separate concerns. The code should compile and all tests should pass at every commit. For example, if you are adding a feature that requires refactoring some code, do the refactoring in a separate commit (or series of commits) from introducing the new feature. Each commit message should describe the particular bit of refactoring in the commit and why it was needed. It's especially important to use separate commits when moving and modifying code. If you need to move a large block of code from one place to another, try your best to do it in an individual commit that is purely a block cut/paste without making any modifications to the code. Then, actually modify the code in the next commit.
 
-* **Don't push fixup commits.** When your reviewer asks for changes, they will want you to rewrite your branch history so that the commit history is clean. We don't want have "fixup commits" in our history, but we also don't want to squash-merge a clean commit series and lose the information it prodes. You may want to familiarize yourself with `git commit --fixup` -- it makes it relatively easy to rewrite history.
+* **Don't push fixup commits.** When your reviewer asks for changes, they will want you to rewrite your branch history so that the commit history is clean. We don't want have "fixup commits" in our history, but we also don't want to squash-merge a clean commit series and lose the information it provides. You may want to familiarize yourself with `git commit --fixup` -- it makes it relatively easy to rewrite history.
 
-* **Push fixups and rebases separately.** When a reviewer asks for changes, they will wan to review what you changce separately from what was already written. It is very important, therefore, that any time you force-push an update to your PR, the push _either_ contains new changes of yours, _or_ rebases onto the latest version of the `main` branch, but _never_ both as the same time. If you do both at once, when your reviewer clicks the "view changes" button, they won't be able to tell which changes are yours vs. new changes to the main branch. In this case they may ask you to revert and try again.
+* **Push fixups and rebases separately.** When a reviewer asks for changes, they will wan to review what you change separately from what was already written. It is very important, therefore, that any time you force-push an update to your PR, the push _either_ contains new changes of yours, _or_ rebases onto the latest version of the `main` branch, but _never_ both as the same time. If you do both at once, when your reviewer clicks the "view changes" button, they won't be able to tell which changes are yours vs. new changes to the main branch. In this case they may ask you to revert and try again.
 
 * **Use three-way conflict markers.** Unfortunately, it is very hard for code reviewers to review conflict resolutions in general, and this can be a source of bugs. You can reduce the probability of bugs by making sure you've enabled three-way conflict markers in git, by running `git config --global merge.conflictstyle diff3`. This makes conflicts much easier to understand, by showing not just "yours" and "theirs", but also the original code from which both were derived.