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: #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>

doc/api/addons.md

@@ -37,7 +37,7 @@ involving knowledge of several components and APIs :
    See [Linking to Node.js' own dependencies][] for additional information.
 
 All of the following examples are available for [download][] and may
-be used as a starting-point for your own Addon.
+be used as the starting-point for an Addon.
 
 ## Hello world
 
@@ -98,7 +98,7 @@ Addon module name is `addon`.
 
 Once the source code has been written, it must be compiled into the binary
 `addon.node` file. To do so, create a file called `binding.gyp` in the
-top-level of the project describing the build configuration of your module
+top-level of the project describing the build configuration of the module
 using a JSON-like format. This file is used by [node-gyp][] -- a tool written
 specifically to compile Node.js Addons.
 

doc/api/child_process.md

@@ -808,8 +808,8 @@ The `'error'` event is emitted whenever:
 2. The process could not be killed, or
 3. Sending a message to the child process failed.
 
-Note that the `'exit'` event may or may not fire after an error has occurred.
-If you are listening to both the `'exit'` and `'error'` events, it is important
+*Note*: The `'exit'` event may or may not fire after an error has occurred.
+When listening to both the `'exit'` and `'error'` events, it is important
 to guard against accidentally invoking handler functions multiple times.
 
 See also [`child.kill()`][] and [`child.send()`][].

doc/api/cli.md

@@ -5,7 +5,7 @@
 Node.js comes with a variety of CLI options. These options expose built-in
 debugging, multiple ways to execute scripts, and other helpful runtime options.
 
-To view this documentation as a manual page in your terminal, run `man node`.
+To view this documentation as a manual page in a terminal, run `man node`.
 
 
 ## Synopsis

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) => {

doc/api/console.md

@@ -257,7 +257,7 @@ added: v0.1.104
 * `label` {string}
 
 Starts a timer that can be used to compute the duration of an operation. Timers
-are identified by a unique `label`. Use the same `label` when you call
+are identified by a unique `label`. Use the same `label` when calling
 [`console.timeEnd()`][] to stop the timer and output the elapsed time in
 milliseconds to `stdout`. Timer durations are accurate to the sub-millisecond.
 

doc/api/dgram.md

@@ -301,9 +301,8 @@ The only way to know for sure that the datagram has been sent is by using a
 passed as the first argument to the `callback`. If a `callback` is not given,
 the error is emitted as an `'error'` event on the `socket` object.
 
-Offset and length are optional, but if you specify one you would need to
-specify the other. Also, they are supported only when the first
-argument is a `Buffer` or `Uint8Array`.
+Offset and length are optional but both *must* be set if either are used.
+They are supported only when the first argument is a `Buffer` or `Uint8Array`.
 
 Example of sending a UDP packet to a random port on `localhost`;
 
@@ -329,8 +328,10 @@ client.send([buf1, buf2], 41234, (err) => {
 });
 ```
 
-Sending multiple buffers might be faster or slower depending on your
-application and operating system: benchmark it. Usually it is faster.
+Sending multiple buffers might be faster or slower depending on the
+application and operating system. It is important to run benchmarks to
+determine the optimal strategy on a case-by-case basis. Generally speaking,
+however, sending multiple buffers is faster.
 
 **A Note about UDP datagram size**
 

doc/api/documentation.md

@@ -21,18 +21,18 @@ documentation is generated using the `tools/doc/generate.js` program.
 The HTML template is located at `doc/template.html`.
 
 
-If you find an error in this documentation, please [submit an issue][]
+If errors are found in this documentation, please [submit an issue][]
 or see [the contributing guide][] for directions on how to submit a patch.
 
 ## Stability Index
 
 <!--type=misc-->
 
-Throughout the documentation, you will see indications of a section's
-stability.  The Node.js API is still somewhat changing, and as it
-matures, certain parts are more reliable than others.  Some are so
+Throughout the documentation are indications of a section's
+stability. The Node.js API is still somewhat changing, and as it
+matures, certain parts are more reliable than others. Some are so
 proven, and so relied upon, that they are unlikely to ever change at
-all.  Others are brand new and experimental, or known to be hazardous
+all. Others are brand new and experimental, or known to be hazardous
 and in the process of being redesigned.
 
 The stability indices are as follows:

doc/api/domain.md

@@ -27,16 +27,16 @@ exit immediately with an error code.
 
 <!-- type=misc -->
 
-Domain error handlers are not a substitute for closing down your
+Domain error handlers are not a substitute for closing down a
 process when an error occurs.
 
 By the very nature of how [`throw`][] works in JavaScript, there is almost
 never any way to safely "pick up where you left off", without leaking
 references, or creating some other sort of undefined brittle state.
 
 The safest way to respond to a thrown error is to shut down the
-process.  Of course, in a normal web server, you might have many
-connections open, and it is not reasonable to abruptly shut those down
+process. Of course, in a normal web server, there may be many
+open connections, and it is not reasonable to abruptly shut those down
 because an error was triggered by someone else.
 
 The better approach is to send an error response to the request that
@@ -80,11 +80,11 @@ const cluster = require('cluster');
 const PORT = +process.env.PORT || 1337;
 
 if (cluster.isMaster) {
-  // In real life, you'd probably use more than just 2 workers,
+  // A more realistic scenario would have more than 2 workers,
   // and perhaps not put the master and worker in the same file.
   //
-  // You can also of course get a bit fancier about logging, and
-  // implement whatever custom logic you need to prevent DoS
+  // It is also possible to get a bit fancier about logging, and
+  // implement whatever custom logic is needed to prevent DoS
   // attacks and other bad behavior.
   //
   // See the options in the cluster documentation.
@@ -161,7 +161,7 @@ if (cluster.isMaster) {
 }
 
 // This part is not important.  Just an example routing thing.
-// You'd put your fancy application logic here.
+// Put fancy application logic here.
 function handleRequest(req, res) {
   switch (req.url) {
     case '/error':
@@ -202,16 +202,16 @@ the active domain at the time of their creation.
 
 Additionally, callbacks passed to lowlevel event loop requests (such as
 to fs.open, or other callback-taking methods) will automatically be
-bound to the active domain.  If they throw, then the domain will catch
+bound to the active domain. If they throw, then the domain will catch
 the error.
 
 In order to prevent excessive memory usage, Domain objects themselves
 are not implicitly added as children of the active domain.  If they
 were, then it would be too easy to prevent request and response objects
 from being properly garbage collected.
 
-If you *want* to nest Domain objects as children of a parent Domain,
-then you must explicitly add them.
+To nest Domain objects as children of a parent Domain they must be explicitly
+added.
 
 Implicit binding routes thrown errors and `'error'` events to the
 Domain's `'error'` event, but does not register the EventEmitter on the