Typo fix

docs/APIReference.md

@@ -12,7 +12,7 @@ examples directory.
 
 | Macro | Description |
 | :--- | :--- |
-| **`CIVETWEB_VERSION`** | The current version of the software as a string with the major and minor version number separated with a dot. For version 1.9, this string will have the value "1.9", for thw first patch of this version "1.9.1". |
+| **`CIVETWEB_VERSION`** | The current version of the software as a string with the major and minor version number separated with a dot. For version 1.9, this string will have the value "1.9", for the first patch of this version "1.9.1". |
 | **`CIVETWEB_VERSION_MAJOR`** | The current major version as number, e.g., (1) for version 1.9. |
 | **`CIVETWEB_VERSION_MINOR`** | The current minor version as number, e.g., (9) for version 1.9. |
 | **`CIVETWEB_VERSION_PATCH`** | The current patch version as number, e.g., (0) for version 1.9 or (1) for version 1.9.1. |

docs/Contribution.md

@@ -26,7 +26,7 @@ Why does a pull request need a description?
 ---
 
 I'm asking for this, because I usually review all pull requests.
-Fhe first thing I check is: "What is the intention of the fix **according to the description**?" and "Does the code really fix it?".
+The first thing I check is: "What is the intention of the fix **according to the description**?" and "Does the code really fix it?".
 Second: "Do I except side effects?".
 Third: "Is there a better way to fix the issue **explained in the description**?"
 I don't like to "reverse engineer" the intention of the fix from the diff (although it may be obvious to the author of the PR, sometimes it's not for others). But you should also do it for yourself: You will get early feedback if your changes are not doing what you expect, or if there is a much more effective way to reach the same goal. Finally it will help all other users, since it helps writing better release notes.