docs: removed Note word from notes

GeorgeSapkin · GeorgeSapkin · commit fad2d6b1524a · 2020-11-16T13:36:23.000+01:00
diff --git a/locale/en/docs/guides/anatomy-of-an-http-transaction.md b/locale/en/docs/guides/anatomy-of-an-http-transaction.md
@@ -57,7 +57,7 @@ relatively painless by putting handy properties onto the `request` object.
 const { method, url } = request;
 ```
 
-> **Note:** The `request` object is an instance of [`IncomingMessage`][].
+> The `request` object is an instance of [`IncomingMessage`][].
 
 The `method` here will always be a normal HTTP method/verb. The `url` is the
 full URL without the server, protocol or port. For a typical URL, this means
@@ -102,7 +102,7 @@ request.on('data', (chunk) => {
 });
 ```
 
-> **Note:** This may seem a tad tedious, and in many cases, it is. Luckily,
+> This may seem a tad tedious, and in many cases, it is. Luckily,
 > there are modules like [`concat-stream`][] and [`body`][] on [`npm`][] which can
 > help hide away some of this logic. It's important to have a good understanding
 > of what's going on before going down that road, and that's why you're here!
@@ -230,7 +230,7 @@ last bit of data on the stream, so we can simplify the example above as follows.
 response.end('<html><body><h1>Hello, World!</h1></body></html>');
 ```
 
-> **Note:** It's important to set the status and headers *before* you start
+> It's important to set the status and headers *before* you start
 > writing chunks of data to the body. This makes sense, since headers come before
 > the body in HTTP responses.
 
@@ -330,7 +330,7 @@ http.createServer((request, response) => {
 }).listen(8080);
 ```
 
-> **Note:** By checking the URL in this way, we're doing a form of "routing".
+> By checking the URL in this way, we're doing a form of "routing".
 > Other forms of routing can be as simple as `switch` statements or as complex as
 > whole frameworks like [`express`][]. If you're looking for something that does
 > routing and nothing else, try [`router`][].
diff --git a/locale/en/docs/guides/backpressuring-in-streams.md b/locale/en/docs/guides/backpressuring-in-streams.md
@@ -81,7 +81,7 @@ 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
+> 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
@@ -354,7 +354,7 @@ 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
+> 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
@@ -410,7 +410,7 @@ stream:
                                        +============+
 ```
 
-> **Note:** If you are setting up a pipeline to chain together a few streams to
+> 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.
 
@@ -450,7 +450,7 @@ 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
+> 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,
diff --git a/locale/en/docs/guides/event-loop-timers-and-nexttick.md b/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.
+> 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,7 +65,7 @@ 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
+> 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
diff --git a/locale/en/docs/guides/timers-in-node.md b/locale/en/docs/guides/timers-in-node.md
@@ -91,7 +91,7 @@ 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
+> 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
