doc: replace uses of `you` and other style nits

Replace uses of the pronouns `you` and `your` throughout
the docs + other minor style nits

PR-URL: https://github.com/nodejs/node/pull/12673
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>

1 files changed, 38 insertions, 39 deletions

diff --git a/doc/api/cluster.md b/doc/api/cluster.md
index 858c98dab67..97c4610da54 100644
--- a/doc/api/cluster.md
+++ b/doc/api/cluster.md
@@ -6,8 +6,8 @@ A single instance of Node.js runs in a single thread. To take advantage of
 multi-core systems the user will sometimes want to launch a cluster of Node.js
 processes to handle the load.
 
-The cluster module allows you to easily create child processes that
-all share server ports.
+The cluster module allows easy creation of child processes that all share
+server ports.
 
 ```js
 const cluster = require('cluster');
@@ -88,27 +88,24 @@ Node.js process and a cluster worker differs:
    idea of what the number 7 file descriptor references.
 2. `server.listen(handle)` Listening on handles explicitly will cause
    the worker to use the supplied handle, rather than talk to the master
-   process.  If the worker already has the handle, then it's presumed
-   that you know what you are doing.
+   process.
 3. `server.listen(0)` Normally, this will cause servers to listen on a
    random port.  However, in a cluster, each worker will receive the
    same "random" port each time they do `listen(0)`.  In essence, the
-   port is random the first time, but predictable thereafter.  If you
-   want to listen on a unique port, generate a port number based on the
-   cluster worker ID.
+   port is random the first time, but predictable thereafter. To listen
+   on a unique port, generate a port number based on the cluster worker ID.
 
-There is no routing logic in Node.js, or in your program, and no shared
-state between the workers.  Therefore, it is important to design your
-program such that it does not rely too heavily on in-memory data objects
-for things like sessions and login.
+*Note*: Node.js does not provide routing logic. It is, therefore important to
+design an application such that it does not rely too heavily on in-memory data
+objects for things like sessions and login.
 
 Because workers are all separate processes, they can be killed or
-re-spawned depending on your program's needs, without affecting other
+re-spawned depending on a program's needs, without affecting other
 workers.  As long as there are some workers still alive, the server will
 continue to accept connections.  If no workers are alive, existing connections
-will be dropped and new connections will be refused.  Node.js does not
-automatically manage the number of workers for you, however.  It is your
-responsibility to manage the worker pool for your application's needs.
+will be dropped and new connections will be refused. Node.js does not
+automatically manage the number of workers, however. It is the application's
+responsibility to manage the worker pool based on its own needs.
 
 
 
@@ -141,7 +138,7 @@ added: v0.7.3
 
 This event is the same as the one provided by [`child_process.fork()`][].
 
-In a worker you can also use `process.on('error')`.
+Within a worker, `process.on('error')` may also be used.
 
 ### Event: 'exit'
 <!-- YAML
@@ -192,8 +189,9 @@ added: v0.7.0
 * `message` {Object}
 * `handle` {undefined|Object}
 
-Similar to the `cluster.on('message')` event, but specific to this worker. In a
-worker you can also use `process.on('message')`.
+Similar to the `cluster.on('message')` event, but specific to this worker.
+
+Within a worker, `process.on('message)` may also be used.
 
 See [`process` event: `'message'`][].
 
@@ -336,9 +334,9 @@ added: v6.0.0
 
 Set by calling `.kill()` or `.disconnect()`. Until then, it is `undefined`.
 
-The boolean `worker.exitedAfterDisconnect` lets you distinguish between voluntary
-and accidental exit, the master may choose not to respawn a worker based on
-this value.
+The boolean `worker.exitedAfterDisconnect` allows distinguishing between
+voluntary and accidental exit, the master may choose not to respawn a worker
+based on this value.
 
 ```js
 cluster.on('exit', (worker, code, signal) => {
@@ -369,9 +367,9 @@ cluster.workers
 added: v0.11.14
 -->
 
-This function returns `true` if the worker is connected to its master via its IPC
-channel, `false` otherwise. A worker is connected to its master after it's been
-created. It is disconnected after the `'disconnect'` event is emitted.
+This function returns `true` if the worker is connected to its master via its
+IPC channel, `false` otherwise. A worker is connected to its master after it
+has been created. It is disconnected after the `'disconnect'` event is emitted.
 
 ### worker.isDead()
 <!-- YAML
@@ -469,7 +467,7 @@ An alias to [`worker.exitedAfterDisconnect`][].
 
 Set by calling `.kill()` or `.disconnect()`. Until then, it is `undefined`.
 
-The boolean `worker.suicide` lets you distinguish between voluntary
+The boolean `worker.suicide` is used to distinguish between voluntary
 and accidental exit, the master may choose not to respawn a worker based on
 this value.
 
@@ -540,7 +538,7 @@ added: v0.7.0
 * `worker` {cluster.Worker}
 
 When a new worker is forked the cluster module will emit a `'fork'` event.
-This can be used to log worker activity, and create your own timeout.
+This can be used to log worker activity, and create a custom timeout.
 
 ```js
 const timeouts = [];
@@ -568,13 +566,14 @@ added: v0.7.0
 * `worker` {cluster.Worker}
 * `address` {Object}
 
-After calling `listen()` from a worker, when the `'listening'` event is emitted on
-the server, a `'listening'` event will also be emitted on `cluster` in the master.
+After calling `listen()` from a worker, when the `'listening'` event is emitted
+on the server a `'listening'` event will also be emitted on `cluster` in the
+master.
 
-The event handler is executed with two arguments, the `worker` contains the worker
-object and the `address` object contains the following connection properties:
-`address`, `port` and `addressType`. This is very useful if the worker is listening
-on more than one address.
+The event handler is executed with two arguments, the `worker` contains the
+worker object and the `address` object contains the following connection
+properties: `address`, `port` and `addressType`. This is very useful if the
+worker is listening on more than one address.
 
 ```js
 cluster.on('listening', (worker, address) => {
@@ -610,8 +609,9 @@ See [child_process event: 'message'][].
 Before Node.js v6.0, this event emitted only the message and the handle,
 but not the worker object, contrary to what the documentation stated.
 
-If you need to support older versions and don't need the worker object,
-you can work around the discrepancy by checking the number of arguments:
+If support for older versions is required but a worker object is not
+required, it is possible to work around the discrepancy by checking the
+number of arguments:
 
 ```js
 cluster.on('message', (worker, message, handle) => {
@@ -713,8 +713,8 @@ added: v0.11.2
 
 The scheduling policy, either `cluster.SCHED_RR` for round-robin or
 `cluster.SCHED_NONE` to leave it to the operating system. This is a
-global setting and effectively frozen once you spawn the first worker
-or call `cluster.setupMaster()`, whatever comes first.
+global setting and effectively frozen once either the first worker is spawned,
+or `cluster.setupMaster()` is called, whichever comes first.
 
 `SCHED_RR` is the default on all operating systems except Windows.
 Windows will change to `SCHED_RR` once libuv is able to effectively
@@ -750,7 +750,7 @@ changes:
 After calling `.setupMaster()` (or `.fork()`) this settings object will contain
 the settings, including the default values.
 
-This object is not supposed to be changed or set manually, by you.
+This object is not intended to be changed or set manually.
 
 ## cluster.setupMaster([settings])
 <!-- YAML
@@ -850,8 +850,7 @@ eachWorker((worker) => {
 });
 ```
 
-Should you wish to reference a worker over a communication channel, using
-the worker's unique id is the easiest way to find the worker.
+Using the worker's unique id is the easiest way to locate the worker.
 
 ```js
 socket.on('data', (id) => {