Fix a few typos in docs/ folder.

docs/build_system.md

@@ -174,7 +174,7 @@ using.
 #### Adding tests to a suite
 #### Running individual tests
 
-## Modifying the buid system
+## Modifying the build system
 ### What is SCons?
 #### `SConstruct` and `SConscripts`
 #### `Environments `and their `Clone`s

docs/evergreen-testing/configuration.md

@@ -13,7 +13,7 @@ section of the Evergreen wiki.
 ### `mongodb-mongo-master`
 The main project for testing MongoDB's dev environments with a number build variants,
 each one corresponding to a particular compile or testing environment to support development.
-Each build variant runs a set of tasks; each task ususally runs one or more tests.
+Each build variant runs a set of tasks; each task usually runs one or more tests.
 
 ### `mongodb-mongo-master-nightly
 Tracks the same branch as `mongodb-mongo-master`, each build variant corresponds to a

docs/futures_and_promises.md

@@ -88,7 +88,7 @@ a high level, but we've left out some important details about how they work.
 ### How Are Futures Fulfilled With Values?
 In our example, we looked at how some code that needs to wait for results can use `Future`s to be
 written in an asynchronous, performant way. But some thread running elsewhere needs to actually
-"fulfill" those futures with a value or error. Threads can fulfull the core "promise" of a
+"fulfill" those futures with a value or error. Threads can fulfill the core "promise" of a
 `Future<T>` - that it will eventually contain a `T` or an error - by using the appropriately named
 `Promise<T>` type. Every pending `Future<T>` is associated with exactly one corresponding
 `Promise<T>` that can be used to ready the `Future<T>`, providing it with a value.  (Note that a
@@ -266,7 +266,7 @@ continuation-chaining member functions in [future.h][future], starting above the
 At some point, we may have no more continuations to add to a future chain, and will want to either
 synchronously extract the value or error held in the last future of the chain, or add a callback to
 asynchronously consume this value. The `.get()` and `.getAsync()` members of future-like types
-provide these facilities for terminating a future chain by extracting or asynchronouslyunsly
+provide these facilities for terminating a future chain by extracting or asynchronously
 consuming the result of the chain. The `.getAsync()` function works much like `.onCompletion()`,
 taking a `Status` or `StatusWith<T>` and running regardless of whether or not the previous link in
 the chain resolved with error or success, and running asynchronously when the previous results are

docs/golden_data_test_framework.md

@@ -61,8 +61,8 @@ be included in the diff.
 * When resolving merge conflicts on the expected output files, one of the approaches below SHOULD be 
 used:
   * "Accept theirs", rerun the tests and verify new outputs. This doesn't require knowledge of 
-  production/test code changes in "theirs" branch, but requires re-review and re-acceptance of c
-  hanges done by local branch.
+  production/test code changes in "theirs" branch, but requires re-review and re-acceptance of 
+  changes done by local branch.
   * "Accept yours", rerun the tests and verify the new outputs. This approach requires knowledge of 
   production/test code changes in "theirs" branch. However, if such changes resulted in 
   straightforward and repetitive output changes, like due to printing code change or fixture change,

docs/load_balancer_support.md

@@ -14,7 +14,7 @@ protocol standard.
 e.g., when connecting to a local `mongos` instance, if the `loadBalancerPort` server parameter was set to 20100, the
 connection string must be of the form `"mongodb://localhost:20100/?loadBalanced=true"`.
 
-`mongos` will emit appropiate error messages on connection attempts if these requirements are not
+`mongos` will emit appropriate error messages on connection attempts if these requirements are not
 met.
 
 There are some subtle behavioral differences that these configuration options enable, chief of

docs/logging.md

@@ -222,7 +222,7 @@ Fatal level log statements using `LOGV2_FATAL` perform `fassert` after logging,
 using the provided ID as assert id. `LOGV2_FATAL_NOTRACE` perform
 `fassertNoTrace` and `LOGV2_FATAL_CONTINUE` does not `fassert` allowing for
 continued execution. `LOGV2_FATAL_CONTINUE` is meant to be used when a fatal
-error has occured but a different way of halting execution is desired such as
+error has occurred but a different way of halting execution is desired such as
 `std::terminate` or `fassertFailedWithStatus`.
 
 `LOGV2_FATAL_OPTIONS` performs `fassert` by default like `LOGV2_FATAL` but this
@@ -520,7 +520,7 @@ implemented as a friend function in a class with the following signature:
 
 In some cases a loggable type might be composed as a hierarchy in the C++ type
 system which would lead to a very verbose structured log output as every level
-in the hierarcy needs a name when outputted as JSON. The attribute naming
+in the hierarchy needs a name when outputted as JSON. The attribute naming
 abstraction system can also be used to collapse such hierarchies. Instead of
 making a type loggable it can instead return one or more attributes from its
 members by using `multipleAttrs` in `logAttrs` functions.

docs/thread_pools.md

@@ -4,7 +4,7 @@ A thread pool ([Wikipedia][thread_pools_wikipedia]) accepts and executes
 lightweight work items called "tasks", using a carefully managed group
 of dedicated long-running worker threads. The worker threads perform
 the work items in parallel without forcing each work item to assume the
-burden of starting and destroying a dedicated thead.
+burden of starting and destroying a dedicated thread.
 
 ## Classes