feat(pages): removed deprecated pages, added new pages, updated exist…

…ing ones (nodejs#2742)

.gitignore

@@ -16,3 +16,6 @@ coverage
 .history
 yarn.lock
 .idea/
+
+# Firebase
+firebase-debug.log

CONTRIBUTING.md

@@ -92,8 +92,6 @@ In the case of an objection being raised in a pull request by another collaborat
 * A Pull Request must be opened on the @nodejs/nodejs.dev README file adding the new collaborator to the list (note the order of names)
 * The Pull Request must be approved by at least two members of @nodejs/nodejs.dev, @nodejs/website, or @nodejs/website-redesign
 * Pull Request must remain open for 72 hours without any objections
-* Once the requirements are met and approved, the pull request can be merged and a member of @nodejs/community-committee will add the new member to the [@nodejs/nodejs-dev team](https://github.com/orgs/nodejs/teams/nodejs-dev)
-
 
 ## 🐛 Debugging Failing Checks
 

README.md

@@ -197,7 +197,6 @@ participated in that process.
 [Query issues for "Meeting"][]
 
 [code of conduct]: https://github.com/nodejs/admin/blob/main/CODE_OF_CONDUCT.md
-[community committee]: https://github.com/nodejs/community-committee
 [contributing guidelines]: ./CONTRIBUTING.md
 [figma design]: https://www.figma.com/file/lOxAGGg5KXb6nwie7zXkz6/NJ---Design-System?node-id=22%3A6086
 [meeting notes]: ./meetings

content/about/about.en.md

@@ -11,7 +11,7 @@ scalable network applications. In the following "hello world" example, many
 connections can be handled concurrently. Upon each connection, the callback is
 fired, but if there is no work to be done, Node.js will sleep.
 
-```js
+```javascript
 const http = require('http');
 
 const hostname = '127.0.0.1';
@@ -32,21 +32,22 @@ This is in contrast to today's more common concurrency model, in which OS thread
 are employed. Thread-based networking is relatively inefficient and very
 difficult to use. Furthermore, users of Node.js are free from worries of
 dead-locking the process, since there are no locks. Almost no function in
-Node.js directly performs I/O, so the process never blocks. Because nothing blocks, scalable systems are very reasonable to develop in Node.js.
+Node.js directly performs I/O, so the process never blocks except when the I/O is performed using
+synchronous methods of Node.js standard library. Because nothing blocks, scalable systems are very
+reasonable to develop in Node.js.
 
 If some of this language is unfamiliar, there is a full article on
 [Blocking vs. Non-Blocking][].
 
-***
+---
 
 Node.js is similar in design to, and influenced by, systems like Ruby's
 [Event Machine][] and Python's [Twisted][]. Node.js takes the event model a bit
-further. It presents an [event loop][] as a runtime construct instead of as a library. In other systems, there is always a blocking call to start the
-event-loop.
+further. It presents an [event loop][] as a runtime construct instead of as a library. In other systems,
+there is always a blocking call to start the event-loop.
 Typically, behavior is defined through callbacks at the beginning of a script, and
-at the end a server is started through a blocking call like
-`EventMachine::run()`. In Node.js, there is no such start-the-event-loop call.
-Node.js simply enters the event loop after executing the input script. Node.js
+at the end a server is started through a blocking call like `EventMachine::run()`.
+In Node.js, there is no such start-the-event-loop call. Node.js simply enters the event loop after executing the input script. Node.js
 exits the event loop when there are no more callbacks to perform. This behavior
 is like browser JavaScript — the event loop is hidden from the user.
 
@@ -61,9 +62,9 @@ communicate with. Built upon that same interface is the [`cluster`][] module,
 which allows you to share sockets between processes to enable load balancing
 over your cores.
 
-[Blocking vs. Non-Blocking]: https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/
+[Blocking vs. Non-Blocking]: /learn/overview-of-blocking-vs-non-blocking/
+[`child_process.fork()`]: /api/child_process/
+[`cluster`]: https://nodejs.org/api/cluster.html
+[event loop]: /learn/the-nodejs-event-loop/
 [Event Machine]: https://github.com/eventmachine/eventmachine
 [Twisted]: https://twistedmatrix.com/trac/
-[`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
-[`cluster`]: https://nodejs.org/api/cluster.html
-[event loop]: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

content/about/governance.en.md

@@ -25,12 +25,9 @@ A guide for Collaborators is maintained at [collaborator-guide.md][].
 
 ## Top Level Committees
 
-The project is governed jointly by the [Technical Steering Committee (TSC)][]
-which is responsible for high-level guidance of the project, and the
-[Community Committee (CommComm)][] which is responsible for guiding and
-extending the Node.js community.
+The project is governed by the [Technical Steering Committee (TSC)][]
+which is responsible for high-level guidance of the project.
 
-[Community Committee (CommComm)]: https://github.com/nodejs/community-committee/blob/main/Community-Committee-Charter.md
 [Consensus Seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making
 [README.md]: https://github.com/nodejs/node/blob/main/README.md#current-project-team-members
 [TSC]: https://github.com/nodejs/TSC

content/about/governance.fr.md

@@ -26,12 +26,9 @@ Un guide pour les collaborateurs est maintenu à [collaborator-guide.md][].
 
 ## Comités de haut niveau
 
-Le projet est dirigé conjointement par le [Comité directeur technique (TSC)][]
-qui est responsable de l'orientation de haut niveau du projet, et le
-[comité de la communauté (CommComm)][] qui est responsable de l'orientation et de
-l'extension de la communauté Node.js.
+Le projet est dirigé par le [Comité directeur technique (TSC)][]
+qui est responsable de l'orientation de haut niveau du projet
 
-[comité de la communauté (CommComm)]: https://github.com/nodejs/community-committee/blob/main/Community-Committee-Charter.md
 [recherche de consensus]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making
 [README.md]: https://github.com/nodejs/node/blob/main/README.md#current-project-team-members
 [TSC]: https://github.com/nodejs/TSC

content/about/releases.fr.md

@@ -3,7 +3,7 @@ title: releases
 displayTitle: Sorties
 description: "Sorties | Node.js"
 authors: ZYSzys, nstanard,  mikeal, fhemberger, garybernhardt, piepmatz, boneskull, bjb568, AugustinMauroy
-category: releases
+category: about
 ---
 
 Les versions majeures de Node.js passent au statut de version _Current_ pendant six mois, ce qui donne aux auteurs de bibliothèques le temps d'ajouter la prise en charge de ces versions.

content/about/security.en.md

@@ -6,38 +6,31 @@ authors: reedloden,XhmikosR,Trott,fhemberger,MaledongGit,yous,sam-github,vdeturc
 category: about
 ---
 
-## Reporting a Bug in Node.js
+## Reporting a bug in Node.js
 
 Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs).
 
-Your report will be acknowledged within 24 hours, and you’ll receive a more
-detailed response to your report within 48 hours indicating the next steps in
+Your report will be acknowledged within 5 days, and you'll receive a more
+detailed response to your report within 10 days indicating the next steps in
 handling your submission.
 
 After the initial reply to your report, the security team will endeavor to keep
 you informed of the progress being made towards a fix and full announcement,
 and may ask for additional information or guidance surrounding the reported
 issue.
 
-### Node.js Bug Bounty Program
+### Node.js bug bounty program
 
 The Node.js project engages in an official bug bounty program for security
-researchers and responsible public disclosures. The program is managed through
+researchers and responsible public disclosures.  The program is managed through
 the HackerOne platform. See <https://hackerone.com/nodejs> for further details.
 
-## Reporting a Bug in a third party module
+## Reporting a bug in a third party module
 
 Security bugs in third party modules should be reported to their respective
-maintainers and should also be coordinated through the Node.js Ecosystem
-Security Team via [HackerOne](https://hackerone.com/nodejs-ecosystem).
+maintainers.
 
-Details regarding this process can be found in the
-[Security Working Group repository](https://github.com/nodejs/security-wg/tree/main/processes/vuln_db.md).
-
-Thank you for improving the security of Node.js and its ecosystem. Your efforts
-and responsible disclosure are greatly appreciated and will be acknowledged.
-
-## Disclosure Policy
+## Disclosure policy
 
 Here is the security disclosure policy for Node.js
 
@@ -62,19 +55,19 @@ Here is the security disclosure policy for Node.js
 
 * This process can take some time, especially when coordination is required
   with maintainers of other projects. Every effort will be made to handle the
-  bug in as timely a manner as possible; however, it’s important that we follow
+  bug in as timely a manner as possible; however, it's important that we follow
   the release process above to ensure that the disclosure is handled in a
   consistent manner.
 
-## Receiving Security Updates
+## Receiving security updates
 
 Security notifications will be distributed via the following methods.
 
 * <https://groups.google.com/group/nodejs-sec>
 * <https://nodejs.org/en/blog/>
 
-## Comments on this Policy
+## Comments on this policy
 
 If you have suggestions on how this process could be improved please submit a
-[pull request](https://github.com/nodejs/nodejs.dev) or
+[pull request](https://github.com/nodejs/nodejs.org) or
 [file an issue](https://github.com/nodejs/security-wg/issues/new) to discuss.