corrections

docs/child-loggers.md

@@ -53,8 +53,8 @@ benchPinoExtremeChildChild*10000: 127.753ms
 It's possible for naming conflicts to arise between child loggers and
 children of child loggers.
 
-This isn't as bad as it sounds, even if you do use the same keys between
-parent and child loggers Pino resolves the conflict in the sanest way.
+This isn't as bad as it sounds, even if the same keys between
+parent and child loggers are used, Pino resolves the conflict in the sanest way.
 
 For example, consider the following:
 

docs/extreme.md

@@ -26,19 +26,19 @@ This has a couple of important caveats:
   + `SIGTERM`
 
   In all of these cases, except `SIGHUP`, the process is in a state that it
-  *must* terminate. Thus, if you do not register an `onTerminated` function when
-  constructing your Pino instance (see [pino#constructor](api.md#constructor)),
+  *must* terminate. Thus, if an `onTerminated` function isn't registered when
+  constructing a Pino instance (see [pino#constructor](api.md#constructor)),
   then Pino will invoke `process.exit(0)` when no error has occurred, or
-  `process.exit(1)` otherwise. If you do supply an `onTerminated` function, it
-  is left up to you to fully terminate the process.
+  `process.exit(1)` otherwise. If an `onTerminated` function is supplied, it 
+  us the responsibility of the `onTerminated` function to manually exit the process.
 
   In the case of `SIGHUP`, we will look to see if any other handlers are
   registered for the event. If not, we will proceed as we do with all other
   signals. If there are more handlers registered than just our own, we will
   simply flush the extreme mode buffer.
 
-So in summary, only use extreme mode if you're doing an extreme amount of
-logging, and you're happy in some scenarios to lose the most recent logs.
+So in summary, only use extreme mode when performing an extreme amount of
+logging and it is acceptable to potentially lose the most recent logs.
 
 ## Usage
 
@@ -67,3 +67,6 @@ buffering.
 In case a synchronous flush is needed, `dest.flushSync()` can be called.
 This method might cause some data loss if a write was already in
 progress, so use it only if truly needed.
+
+* See [`pino.extreme` api](/docs/api.md#pino-extreme)
+* See [`destination` parameter](/docs/api.md#destination)

docs/help.md

@@ -3,7 +3,7 @@
 * [Log rotation](#rotate)
 * [Saving to multiple files](#multiple)
 * [Log Filtering](#filter-logs)
-* [How do I use a transport with systemd?](#transport-systemd)
+* [Transports and systemd](#transport-systemd)
 * [Duplicate keys](#dupe-keys)
 * [Log levels as labels instead of numbers](#level-string)
 * [Pino with `debug`](#debug)
@@ -16,7 +16,7 @@ We recommend [logrotate](https://github.com/logrotate/logrotate).
 Consider we output our logs to `/var/log/myapp.log` like so:
 
 ```
-> node server.js > /var/log/myapp.log
+$ node server.js > /var/log/myapp.log
 ```
 
 We would rotate our log files with logrotate, by adding the following to `/etc/logrotate.d/myapp`:
@@ -37,7 +37,7 @@ We would rotate our log files with logrotate, by adding the following to `/etc/l
 <a id="multiple"></a>
 ## Saving to multiple files
 
-Let's assume you want to store all error messages to a separate log file:
+Let's assume we want to store all error messages to a separate log file.
 
 Install [pino-tee](http://npm.im/pino-tee) with:
 
@@ -54,58 +54,62 @@ node app.js | pino-tee warn ./warn-logs > ./all-logs
 
 <a id="filter-logs"></a>
 ## Log Filtering
-The Pino authors are firm believers in using common, pre-existing, system
-utilities. Thus, some recommendations for this are:
+The Pino philosophy advocates common, pre-existing, system utilities. 
+
+Some recommendations in line with this philosophy are:
 
 1. Use [`grep`](https://linux.die.net/man/1/grep):
     ```sh
     $ # View all "INFO" level logs
-    $ node your_app.js | grep '"level":30'
+    $ node app.js | grep '"level":30'
     ```
 1. Use [`jq`](https://stedolan.github.io/jq/):
     ```sh
     $ # View all "ERROR" level logs
-    $ node node_app.js | jq 'select(.level == 50)'
+    $ node app.js | jq 'select(.level == 50)'
     ```
 
 <a id="transport-systemd"></a>
-## How do I use a transport with systemd?
+## Transports and systemd
 `systemd` makes it complicated to use pipes in services. One method for overcoming
 this challenge is to use a subshell:
 
 ```
-ExecStart=/bin/sh -c '/path/to/node your_app.js | pino-transport'
+ExecStart=/bin/sh -c '/path/to/node app.js | pino-transport'
 ```
 
 <a id="dupe-keys"></a>
 ## How Pino handles duplicate keys
-See the documentation on [duplicate keys](https://github.com/pinojs/pino#duplicate-keys).
+
+Duplicate keys are possibly when a child logger logs an object with a key that
+collides with a key in the child loggers bindings. 
+
+See the [child logger duplicate keys caveat](/docs/child-loggers.md#duplicate-keys-caveat)
+for information on this is handled.
 
 <a id="level-string"></a>
 ## Log levels as labels instead of numbers
 Pino log lines are meant to be parseable. Thus, there isn't any built-in option
 to change the level from the integer value to the string name. However, there
 are a couple of options:
 
-1. If the only change desired is the name, i.e. you want to retain the newline
-delimited JSON, then you can use a transport to make the change. One such
+1. If the only change desired is the name then a transport can be used. One such
 transport is [`pino-text-level-transport`](https://npm.im/pino-text-level-transport).
 1. Use a prettifier like [`pino-pretty`](https://npm.im/pino-pretty) to make
 the logs human friendly.
 
 <a id="debug"></a>
 ## Pino with `debug`
-Capture debug logs in JSON format, at 10x-20x the speed:
-The popular [`debug`](http://npm.im/debug) which
-used in many modules accross the ecosystem.
 
-The [`pino-debug`](http://github.com/pinojs/pino-debug)
-can captures calls to the `debug` loggers and run them
+The popular [`debug`](http://npm.im/debug) is used in many modules across the ecosystem. 
+
+The [`pino-debug`](http://github.com/pinojs/pino-debug) module
+can capture calls to `debug` loggers and run them
 through `pino` instead. This results in a 10x (20x in extreme mode)
-performance improvement, while logging out more information, in the
-usual JSON format.
+performance improvement - event though `pino-debug` is logging additional 
+data and wrapping it in JSON.
 
-The quick start way to enable this is simply to install [`pino-debug`](http://github.com/pinojs/pino-debug)
+To quickly enable this install [`pino-debug`](http://github.com/pinojs/pino-debug)
 and preload it with the `-r` flag, enabling any `debug` logs with the
 `DEBUG` environment variable:
 

docs/legacy.md

@@ -100,6 +100,8 @@ $ npm install -g pino-pretty
 $ node app.js | pino-pretty
 ``` 
 
+* See [Pretty Printing documentation](/docs/pretty.md)
+
 #### Programmatic Pretty Printing
 
 The [`pino.pretty()`](https://github.com/pinojs/pino/blob/v4.x.x/docs/API.md#prettyoptions)
@@ -130,6 +132,7 @@ npm install --save-dev pino-pretty
 ``` 
 
 * See [prettyPrint option](/docs/api.md#prettyPrint)
+* See [Pretty Printing documentation](/docs/pretty.md)
 
 #### Slowtime
 

docs/pretty.md

@@ -49,7 +49,7 @@ module.exports = function myPrettifier (options) {
 ```
 
 The reference implementation of such a module is the [`pino-pretty`][pp] module.
-To learn more about creating your own prettifier module, learn from the
+To learn more about creating a custom prettifier module, refer to the
 `pino-pretty` source code.
 
 Note: if the prettifier returns `undefined`, instead of a formatted line, nothing
@@ -58,7 +58,7 @@ will be written to the destination stream.
 ### API Example
 
 > #### NOTE:
-> For general usage, it is highly recommended that you pipe logs into
+> For general usage, it is highly recommended that logs are piped into
 > the prettifier instead. Prettified logs are not easily parsed and cannot
 > be easily investigated at a later date.
 

docs/redaction.md

@@ -4,11 +4,11 @@ To redact sensitive information, supply paths to keys that hold sensitive data
 using the `redact` option:
 
 ```js
-var pino = require('.')({
+const logger = require('.')({
   redact: ['key', 'path.to.key', 'stuff.thats[*].secret']
 })
 
-pino.info({
+logger.info({
   key: 'will be redacted',
   path: {
     to: {key: 'sensitive', another: 'thing'}
@@ -34,14 +34,14 @@ an object. This allows control over *how* information is redacted.
 For instance, setting the censor: 
 
 ```js
-var pino = require('.')({
+const logger = require('.')({
   redact: {
     paths: ['key', 'path.to.key', 'stuff.thats[*].secret'],
     censor: '**GDPR COMPLIANT**'
   }
 })
 
-pino.info({
+logger.info({
   key: 'will be redacted',
   path: {
     to: {key: 'sensitive', another: 'thing'}
@@ -64,14 +64,14 @@ This will output:
 The `redact.remove` option also allows for the key and value to be removed from output:
 
 ```js
-var pino = require('.')({
+const logger = require('.')({
   redact: {
     paths: ['key', 'path.to.key', 'stuff.thats[*].secret'],
     remove: true
   }
 })
 
-pino.info({
+logger.info({
   key: 'will be redacted',
   path: {
     to: {key: 'sensitive', another: 'thing'}
@@ -98,8 +98,8 @@ See [pino options in API](api.md#pino) for `redact` API details.
 Pino's redaction functionality is built on top of [`fast-redact`](http://github.com/davidmarkclements/fast-redact)
 which adds about 2% overhead to `JSON.stringify` when using paths without wildcards.
 
-When used with pino logger with a single redacted path, any overhead is within noise - we haven't found
-a way to deterministically measure it's effect. This is because its not a bottleneck.
+When used with pino logger with a single redacted path, any overhead is within noise -
+a way to deterministically measure it's effect has not been found. This is because its not a bottleneck.
 
 However, wildcard redaction does carry a non-trivial cost relative to explicitly declaring the keys 
 (50% in a case where four keys are redacted across two objects). See