[Merged by Bors] - Fixing a few typos / documentation

book/src/advanced-datadir.md

@@ -55,5 +55,5 @@ In this case, the user could solve this warn by following these steps:
 1. Restarting the BN process
 
 Although there are no known issues with using backwards compatibility functionality, having split
-directories is likely to cause confusion for users. Therefore, we recommend affected users migrate
+directories is likely to cause confusion for users. Therefore, we recommend that affected users migrate
 to a consolidated directory structure.

book/src/advanced_networking.md

@@ -22,7 +22,7 @@ Having a large peer count means that your node must act as an honest RPC server
 to all your connected peers. If there are many that are syncing, they will
 often be requesting a large number of blocks from your node. This means your
 node must perform a lot of work reading and responding to these peers. If your
-node is over-loaded with peers and cannot respond in time, other Lighthouse
+node is overloaded with peers and cannot respond in time, other Lighthouse
 peers will consider you non-performant and disfavour you from their peer
 stores. Your node will also have to handle and manage the gossip and extra
 bandwidth that comes from having these extra peers. Having a non-responsive
@@ -63,7 +63,7 @@ settings allow you construct your initial ENR. Their primary intention is for
 setting up boot-like nodes and having a contactable ENR on boot. On normal
 operation of a Lighthouse node, none of these flags need to be set. Setting
 these flags incorrectly can lead to your node being incorrectly added to the
-global DHT which will degrades the discovery process for all Ethereum consensus peers.
+global DHT which will degrade the discovery process for all Ethereum consensus peers.
 
 The ENR of a Lighthouse node is initially set to be non-contactable. The
 in-built discovery mechanism can determine if your node is publicly accessible,

book/src/faq.md

@@ -1,14 +1,14 @@
 # Frequently Asked Questions
 
 - [Why does it take so long for a validator to be activated?](#why-does-it-take-so-long-for-a-validator-to-be-activated)
-- [Do I need to set up any port mappings](#do-i-need-to-set-up-any-port-mappings)
+- [Do I need to set up any port mappings?](#do-i-need-to-set-up-any-port-mappings)
 - [I have a low peer count and it is not increasing](#i-have-a-low-peer-count-and-it-is-not-increasing)
 - [What should I do if I lose my slashing protection database?](#what-should-i-do-if-i-lose-my-slashing-protection-database)
 - [How do I update lighthouse?](#how-do-i-update-lighthouse)
 - [I can't compile lighthouse](#i-cant-compile-lighthouse)
-- [What is "Syncing deposit contract block cache"](#what-is-syncing-deposit-contract-block-cache)
+- [What is "Syncing deposit contract block cache"?](#what-is-syncing-deposit-contract-block-cache)
 - [Can I use redundancy in my staking setup?](#can-i-use-redundancy-in-my-staking-setup)
-- [How can I monitor my validators](#how-can-i-monitor-my-validators)
+- [How can I monitor my validators?](#how-can-i-monitor-my-validators)
 
 ### Why does it take so long for a validator to be activated?
 
@@ -86,7 +86,7 @@ repeats until the queue is cleared.
 Once a validator has been activated, there's no more waiting! It's time to
 produce blocks and attestations!
 
-### Do I need to set up any port mappings
+### Do I need to set up any port mappings?
 
 It is not strictly required to open any ports for Lighthouse to connect and
 participate in the network. Lighthouse should work out-of-the-box. However, if
@@ -154,7 +154,7 @@ You will just also need to make sure the code you have checked out is up to date
 
 See [here.](./installation-source.md#troubleshooting)
 
-### What is "Syncing deposit contract block cache"
+### What is "Syncing deposit contract block cache"?
 
 ```
 Nov 30 21:04:28.268 WARN Syncing deposit contract block cache   est_blocks_remaining: initializing deposits, service: slot_notifier

book/src/redundancy.md

@@ -42,7 +42,7 @@ There are a few interesting properties about the list of `--beacon-nodes`:
 - *Synced is preferred*: the validator client prefers a synced beacon node over
 	one that is still syncing.
 - *Failure is sticky*: if a beacon node fails, it will be flagged as offline
-    and wont be retried again for the rest of the slot (12 seconds). This helps prevent the impact
+    and won't be retried again for the rest of the slot (12 seconds). This helps prevent the impact
     of time-outs and other lengthy errors.
 
 > Note: When supplying multiple beacon nodes the `http://localhost:5052` address must be explicitly
@@ -51,7 +51,7 @@ There are a few interesting properties about the list of `--beacon-nodes`:
 
 ### Configuring a redundant Beacon Node
 
-In our previous example we listed `http://192.168.1.1:5052` as a redundant
+In our previous example, we listed `http://192.168.1.1:5052` as a redundant
 node. Apart from having sufficient resources, the backup node should have the
 following flags: