docs: make note formatting more consistent

Author: GeorgeSapkin

locale/en/docs/guides/backpressuring-in-streams.md

@@ -81,12 +81,12 @@ To test the results, try opening each compressed file. The file compressed by
 the [`zip(1)`][] tool will notify you the file is corrupt, whereas the
 compression finished by [`Stream`][] will decompress without error.
 
-Note: In this example, we use `.pipe()` to get the data source from one end
-to the other. However, notice there are no proper error handlers attached. If
-a chunk of data were to fail to be properly received, the `Readable` source or
-`gzip` stream will not be destroyed. [`pump`][] is a utility tool that would
-properly destroy all the streams in a pipeline if one of them fails or closes,
-and is a must have in this case!
+> **Note:** In this example, we use `.pipe()` to get the data source from one end
+> to the other. However, notice there are no proper error handlers attached. If
+> a chunk of data were to fail to be properly received, the `Readable` source or
+> `gzip` stream will not be destroyed. [`pump`][] is a utility tool that would
+> properly destroy all the streams in a pipeline if one of them fails or closes,
+> and is a must have in this case!
 
 [`pump`][] is only necessary for Node.js 8.x or earlier, as for Node.js 10.x
 or later version, [`pipeline`][] is introduced to replace for [`pump`][].
@@ -354,11 +354,11 @@ Well the answer is simple: Node.js does all of this automatically for you.
 That's so great! But also not so great when we are trying to understand how to
 implement our own custom streams.
 
-Note: In most machines, there is a byte size that determines when a buffer
-is full (which will vary across different machines). Node.js allows you to set
-your own custom [`highWaterMark`][], but commonly, the default is set to 16kb
-(16384, or 16 for objectMode streams). In instances where you might
-want to raise that value, go for it, but do so with caution!
+> **Note:** In most machines, there is a byte size that determines when a buffer
+> is full (which will vary across different machines). Node.js allows you to set
+> your own custom [`highWaterMark`][], but commonly, the default is set to 16kb
+> (16384, or 16 for objectMode streams). In instances where you might
+> want to raise that value, go for it, but do so with caution!
 
 ## Lifecycle of `.pipe()`
 
@@ -410,9 +410,9 @@ stream:
                                        +============+
 ```
 
-Note: If you are setting up a pipeline to chain together a few streams to
-manipulate your data, you will most likely be implementing [`Transform`][]
-stream.
+> **Note:** If you are setting up a pipeline to chain together a few streams to
+> manipulate your data, you will most likely be implementing [`Transform`][]
+> stream.
 
 In this case, your output from your [`Readable`][] stream will enter in the
 [`Transform`][] and will pipe into the [`Writable`][].
@@ -450,11 +450,11 @@ In general,
 3. Streams changes between different Node.js versions, and the library you use.
 Be careful and test things.
 
-Note: In regards to point 3, an incredibly useful package for building
-browser streams is [`readable-stream`][]. Rodd Vagg has written a
-[great blog post][] describing the utility of this library. In short, it
-provides a type of automated graceful degradation for [`Readable`][] streams,
-and supports older versions of browsers and Node.js.
+> **Note:** In regards to point 3, an incredibly useful package for building
+> browser streams is [`readable-stream`][]. Rodd Vagg has written a
+> [great blog post][] describing the utility of this library. In short, it
+> provides a type of automated graceful degradation for [`Readable`][] streams,
+> and supports older versions of browsers and Node.js.
 
 ## Rules specific to Readable Streams
 

locale/en/docs/guides/event-loop-timers-and-nexttick.md

@@ -48,7 +48,7 @@ order of operations.
    └───────────────────────────┘
 ```
 
-*note: each box will be referred to as a "phase" of the event loop.*
+> **Note:** Each box will be referred to as a "phase" of the event loop.
 
 Each phase has a FIFO queue of callbacks to execute. While each phase is
 special in its own way, generally, when the event loop enters a given
@@ -65,11 +65,11 @@ result, long running callbacks can allow the poll phase to run much
 longer than a timer's threshold. See the [**timers**](#timers) and
 [**poll**](#poll) sections for more details.
 
-_**NOTE:** There is a slight discrepancy between the Windows and the
-Unix/Linux implementation, but that's not important for this
-demonstration. The most important parts are here. There are actually
-seven or eight steps, but the ones we care about — ones that Node.js
-actually uses - are those above._
+> **Note:** There is a slight discrepancy between the Windows and the
+> Unix/Linux implementation, but that's not important for this
+> demonstration. The most important parts are here. There are actually
+> seven or eight steps, but the ones we care about — ones that Node.js
+> actually uses - are those above.
 
 ## Phases Overview
 
@@ -99,8 +99,8 @@ scheduled after the specified amount of time has passed; however,
 Operating System scheduling or the running of other callbacks may delay
 them.
 
-_**Note**: Technically, the [**poll** phase](#poll) controls when timers
-are executed._
+> **Note:** Technically, the [**poll** phase](#poll) controls when timers
+> are executed.
 
 For example, say you schedule a timeout to execute after a 100 ms
 threshold, then your script starts asynchronously reading a file which
@@ -145,11 +145,11 @@ the timer's callback. In this example, you will see that the total delay
 between the timer being scheduled and its callback being executed will
 be 105ms.
 
-Note: To prevent the **poll** phase from starving the event loop, [libuv][]
-(the C library that implements the Node.js
-event loop and all of the asynchronous behaviors of the platform)
-also has a hard maximum (system dependent) before it stops polling for
-more events.
+> **Note:** To prevent the **poll** phase from starving the event loop,
+> [libuv][] (the C library that implements the Node.js
+> event loop and all of the asynchronous behaviors of the platform)
+> also has a hard maximum (system dependent) before it stops polling for
+> more events.
 
 ### pending callbacks
 

locale/en/docs/guides/publishing-napi-modules.md

@@ -39,15 +39,15 @@ will look like this:
 }
 ```
 
-**Note:** As explained in
-["Using dist-tags"][], unlike regular versions, tagged versions cannot be
-addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
-reason for this is that the tag refers to exactly one version. So, if the
-package maintainer chooses to tag a later version of the package using the
-same tag, `npm update` will receive the later version. This should be acceptable
-given the currently experimental nature of N-API. To depend on an N-API-enabled
-version other than the latest published, the `package.json` dependency will
-have to refer to the exact version like the following:
+> **Note:** As explained in
+> ["Using dist-tags"][], unlike regular versions, tagged versions cannot be
+> addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
+> reason for this is that the tag refers to exactly one version. So, if the
+> package maintainer chooses to tag a later version of the package using the
+> same tag, `npm update` will receive the later version. This should be acceptable
+> given the currently experimental nature of N-API. To depend on an N-API-enabled
+> version other than the latest published, the `package.json` dependency will
+> have to refer to the exact version like the following:
 
 ```json
 "dependencies": {

locale/en/docs/guides/timers-in-node.md

@@ -91,13 +91,13 @@ executing immediate: so immediate
 `setImmediate()` returns an `Immediate` object, which can be used to cancel
 the scheduled immediate (see `clearImmediate()` below).
 
-Note: Don't get `setImmediate()` confused with `process.nextTick()`. There are
-some major ways they differ. The first is that `process.nextTick()` will run
-*before* any `Immediate`s that are set as well as before any scheduled I/O.
-The second is that `process.nextTick()` is non-clearable, meaning once
-code has been scheduled to execute with `process.nextTick()`, the execution
-cannot be stopped, just like with a normal function. Refer to [this guide](/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick)
-to better understand the operation of `process.nextTick()`.
+> **Note:** Don't get `setImmediate()` confused with `process.nextTick()`. There are
+> some major ways they differ. The first is that `process.nextTick()` will run
+> *before* any `Immediate`s that are set as well as before any scheduled I/O.
+> The second is that `process.nextTick()` is non-clearable, meaning once
+> code has been scheduled to execute with `process.nextTick()`, the execution
+> cannot be stopped, just like with a normal function. Refer to [this guide](/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick)
+> to better understand the operation of `process.nextTick()`.
 
 ### "Infinite Loop" Execution ~ *`setInterval()`*