fix: Remaining auto-fixable remark-lint rules (#1002)

Author: nschonni

.remarkrc

@@ -2,10 +2,7 @@
   "plugins": [
     "remark-gfm",
     "remark-preset-lint-node",
-    ["remark-lint-fenced-code-flag", false],
-    ["remark-lint-first-heading-level", false],
     ["remark-lint-maximum-line-length", false],
-    ["remark-lint-prohibited-strings", false],
-    ["remark-lint-unordered-list-marker-style", false]
+    ["remark-lint-prohibited-strings", false]
   ]
 }

OpenSSL-Strategy.md

@@ -5,8 +5,8 @@ This policy document describes for each release line:
 * Which versions of OpenSSL Node.js will include.
 * Which versions of a "shared" OpenSSL Node.js will support.
 * What version of TLS will be supported
-  - by default,
-  - with run-time configuration.
+  * by default,
+  * with run-time configuration.
 * Whether FIPS will be supported.
 
 It also gives background on OpenSSL release lifetimes, TLS1.3, and FIPS support,
@@ -39,13 +39,15 @@ OpenSSL LTS support timing, the lack of OpenSSL LTS planning and the lack of a
 clear timeframe for a new FIPS module complicates Node.js 10.
 
 For Node.js < 10.16.0:
+
 * OpenSSL version: 1.1.0
 * Allowed shared OpenSSL version: 1.1.0
 * Default minimum TLS version is TLSv1, default maximum is TLSv1.2. No other
   TLS versions are supported by this version of OpenSSL or Node.js.
 * FIPS: not supported
 
 For Node.js >= 10.16.0:
+
 * OpenSSL version: 1.1.1
 * Allowed shared OpenSSL version: 1.1.0 or 1.1.1
 * Default minimum TLS version is TLSv1, default maximum is TLSv1.2. It is
@@ -88,13 +90,15 @@ This release will not be designated LTS. It was updated to include OpenSSL 1.1.1
 in [11.9.0](https://nodejs.org/en/blog/release/v11.9.0/).
 
 For Node.js < 11.9.0:
+
 * OpenSSL version: 1.1.0
 * Allowed shared OpenSSL version: 1.1.0
 * Default minimum TLS version is TLSv1, default maximum is TLSv1.2. No other
   TLS versions are supported by this version of OpenSSL or Node.js.
 * FIPS: not supported
 
 For Node.js >= 11.9.0:
+
 * OpenSSL version: 1.1.0
 * Allowed shared OpenSSL version: 1.1.0 or 1.1.1
 * Default minimum TLS version is TLSv1, default maximum is TLSv1.2. It is
@@ -112,9 +116,10 @@ For Node.js >= 11.9.0:
 * FIPS: not supported
 
 Node.js EOL dates:
-- 12.x: April 2022
-- 13.x: June, 2020
-- 14.x: April 2023
+
+* 12.x: April 2022
+* 13.x: June, 2020
+* 14.x: April 2023
 
 ## Node.js version 15.x (est. Oct 2020) (EOL Jun 2021)
 
@@ -150,6 +155,7 @@ For minimal disruption, it would probably be helpful if Node.js supported
 building against OpenSSL 1.1.1 out-of-tree, even if OpenSSL 3.x was in-tree.
 
 Challenges are:
+
 1. OpenSSL 3.x moved many algorithms into a legacy library, that is only
   accessible as a dynamically loaded provider, so cannot ship with Node.js
 2. Node.js has a build system wrapped around OpenSSL 1.1.1, it is currently

Security-Team.md

@@ -35,16 +35,16 @@ includes a fix, documentation, an informational CVE or blog post.
 
 <!-- ncu-team-sync.team(nodejs/security-triage) -->
 
-- [@bnoordhuis](https://github.com/bnoordhuis) - Ben Noordhuis
-- [@cjihrig](https://github.com/cjihrig) - Colin Ihrig
-- [@indutny](https://github.com/indutny) - Fedor Indutny
-- [@jasnell](https://github.com/jasnell) - James M Snell
-- [@mcollina](https://github.com/mcollina) - Matteo Collina
-- [@MylesBorins](https://github.com/MylesBorins) - Myles Borins
-- [@ronag](https://github.com/ronag) - Robert Nagy
-- [@shigeki](https://github.com/shigeki) - Shigeki Ohtsu
-- [@vdeturckheim](https://github.com/vdeturckheim) - Vladimir de Turckheim
-- [@watson](https://github.com/watson) - Thomas Watson
+* [@bnoordhuis](https://github.com/bnoordhuis) - Ben Noordhuis
+* [@cjihrig](https://github.com/cjihrig) - Colin Ihrig
+* [@indutny](https://github.com/indutny) - Fedor Indutny
+* [@jasnell](https://github.com/jasnell) - James M Snell
+* [@mcollina](https://github.com/mcollina) - Matteo Collina
+* [@MylesBorins](https://github.com/MylesBorins) - Myles Borins
+* [@ronag](https://github.com/ronag) - Robert Nagy
+* [@shigeki](https://github.com/shigeki) - Shigeki Ohtsu
+* [@vdeturckheim](https://github.com/vdeturckheim) - Vladimir de Turckheim
+* [@watson](https://github.com/watson) - Thomas Watson
 
 <!-- ncu-team-sync end -->
 
@@ -54,12 +54,13 @@ The [TSC](https://github.com/nodejs/node#tsc-technical-steering-committee)
 have access.
 
 These non-TSC and TSC Emeriti also have access:
+
 * [bnoordhuis](https://github.com/bnoordhuis) - **Ben Noordhuis**
 * [indutny](https://github.com/indutny) - **Fedor Indutny**
 * [ronag](https://github.com/ronag) - **Robert Nagy**
 * [rvagg](https://github.com/rvagg) - **Rod Vagg**
 * [vdeturckheim](https://github.com/vdeturckheim) - **Vladimir de Turckheim**
-- [@watson](https://github.com/watson) - **Thomas Watson**
+* [@watson](https://github.com/watson) - **Thomas Watson**
 
 List is from the [member page](https://hackerone.com/nodejs/team_members) for
 the Node.js program on HackerOne.
@@ -68,39 +69,39 @@ the Node.js program on HackerOne.
 
 <!-- ncu-team-sync.team(nodejs-private/security) -->
 
-- [@apapirovski](https://github.com/apapirovski) - Anatoli Papirovski
-- [@BethGriggs](https://github.com/BethGriggs) - Bethany Nicolle Griggs
-- [@bnoordhuis](https://github.com/bnoordhuis) - Ben Noordhuis
-- [@BridgeAR](https://github.com/BridgeAR) - Ruben Bridgewater
-- [@ChALkeR](https://github.com/ChALkeR) - Сковорода Никита Андреевич
-- [@cjihrig](https://github.com/cjihrig) - Colin Ihrig
-- [@codebytere](https://github.com/codebytere) - Shelley Vohr
-- [@danbev](https://github.com/danbev) - Daniel Bevenius
-- [@dougwilson](https://github.com/dougwilson) - Douglas Wilson
-- [@evilpacket](https://github.com/evilpacket) - Adam Baldwin
-- [@fhinkel](https://github.com/fhinkel) - F. Hinkelmann
-- [@gabrielschulhof](https://github.com/gabrielschulhof) - Gabriel Schulhof
-- [@gireeshpunathil](https://github.com/gireeshpunathil) - Gireesh Punathil
-- [@indutny](https://github.com/indutny) - Fedor Indutny
-- [@jasnell](https://github.com/jasnell) - James M Snell
-- [@jbergstroem](https://github.com/jbergstroem) - Johan Bergström
-- [@joaocgreis](https://github.com/joaocgreis) - João Reis
-- [@joyeecheung](https://github.com/joyeecheung) - Joyee Cheung
-- [@mcollina](https://github.com/mcollina) - Matteo Collina
-- [@mhdawson](https://github.com/mhdawson) - Michael Dawson
-- [@mmarchini](https://github.com/mmarchini) - mary marchini
-- [@MylesBorins](https://github.com/MylesBorins) - Myles Borins
-- [@richardlau](https://github.com/richardlau) - Richard Lau
-- [@ronag](https://github.com/ronag) - Robert Nagy
-- [@ruyadorno](https://github.com/ruyadorno) - Ruy Adorno
-- [@rvagg](https://github.com/rvagg) - Rod Vagg
-- [@saghul](https://github.com/saghul) - Saúl Ibarra Corretgé
-- [@shigeki](https://github.com/shigeki) - Shigeki Ohtsu
-- [@targos](https://github.com/targos) - Michaël Zasso
-- [@tniessen](https://github.com/tniessen) - Tobias Nießen
-- [@Trott](https://github.com/Trott) - Rich Trott
-- [@vdeturckheim](https://github.com/vdeturckheim) - Vladimir de Turckheim
-- [@watson](https://github.com/watson) - Thomas Watson
+* [@apapirovski](https://github.com/apapirovski) - Anatoli Papirovski
+* [@BethGriggs](https://github.com/BethGriggs) - Bethany Nicolle Griggs
+* [@bnoordhuis](https://github.com/bnoordhuis) - Ben Noordhuis
+* [@BridgeAR](https://github.com/BridgeAR) - Ruben Bridgewater
+* [@ChALkeR](https://github.com/ChALkeR) - Сковорода Никита Андреевич
+* [@cjihrig](https://github.com/cjihrig) - Colin Ihrig
+* [@codebytere](https://github.com/codebytere) - Shelley Vohr
+* [@danbev](https://github.com/danbev) - Daniel Bevenius
+* [@dougwilson](https://github.com/dougwilson) - Douglas Wilson
+* [@evilpacket](https://github.com/evilpacket) - Adam Baldwin
+* [@fhinkel](https://github.com/fhinkel) - F. Hinkelmann
+* [@gabrielschulhof](https://github.com/gabrielschulhof) - Gabriel Schulhof
+* [@gireeshpunathil](https://github.com/gireeshpunathil) - Gireesh Punathil
+* [@indutny](https://github.com/indutny) - Fedor Indutny
+* [@jasnell](https://github.com/jasnell) - James M Snell
+* [@jbergstroem](https://github.com/jbergstroem) - Johan Bergström
+* [@joaocgreis](https://github.com/joaocgreis) - João Reis
+* [@joyeecheung](https://github.com/joyeecheung) - Joyee Cheung
+* [@mcollina](https://github.com/mcollina) - Matteo Collina
+* [@mhdawson](https://github.com/mhdawson) - Michael Dawson
+* [@mmarchini](https://github.com/mmarchini) - mary marchini
+* [@MylesBorins](https://github.com/MylesBorins) - Myles Borins
+* [@richardlau](https://github.com/richardlau) - Richard Lau
+* [@ronag](https://github.com/ronag) - Robert Nagy
+* [@ruyadorno](https://github.com/ruyadorno) - Ruy Adorno
+* [@rvagg](https://github.com/rvagg) - Rod Vagg
+* [@saghul](https://github.com/saghul) - Saúl Ibarra Corretgé
+* [@shigeki](https://github.com/shigeki) - Shigeki Ohtsu
+* [@targos](https://github.com/targos) - Michaël Zasso
+* [@tniessen](https://github.com/tniessen) - Tobias Nießen
+* [@Trott](https://github.com/Trott) - Rich Trott
+* [@vdeturckheim](https://github.com/vdeturckheim) - Vladimir de Turckheim
+* [@watson](https://github.com/watson) - Thomas Watson
 
 <!-- ncu-team-sync end -->
 
@@ -113,9 +114,9 @@ Report states are described in HackerOne [docs](https://docs.hackerone.com/progr
 The expected workflow for issues reported to Node.js is:
 
 1. `NEW`: issue reported (initial state).  Issues in this state are in the
-  process of being analyzed with the intention to move them into either
-  `TRIAGED`, `NEEDS-MORE-INFO`, or one of the "Closed" states
-  (`NOT-APPLICABLE`, `INFORMATIVE`, etc.). Has several sub-states:
+    process of being analyzed with the intention to move them into either
+    `TRIAGED`, `NEEDS-MORE-INFO`, or one of the "Closed" states
+    (`NOT-APPLICABLE`, `INFORMATIVE`, etc.). Has several sub-states:
     1. `H1 Triage`: Issues start off assigned to the `H1 Triage` team. That team
       does initial triage. They ask for a runnable reproduction, they run it,
       and they verify whether it does in fact appear to demonstrate a
@@ -129,36 +130,36 @@ The expected workflow for issues reported to Node.js is:
       When further progress on the issue is blocked on response from the reporter,
       this is the state.
 2. `TRIAGED`: State for an issue when it is a non-duplicate and resolvable.
-  Issues in this state are waiting for the Node.js team to take some action to
-  resolve them. Typically, this would be publishing a Node.js release that
-  resolves the issue, but it could also be publishing documentation, or making
-  a configuration change to our infrastructure for a <https://nodejs.org>
-  problem. The expected resolution should be described in a comment on the
-  issue when it is moved to `TRIAGED`.
-    - ...: There are no explicit states for an issue as it is in process of
+    Issues in this state are waiting for the Node.js team to take some action to
+    resolve them. Typically, this would be publishing a Node.js release that
+    resolves the issue, but it could also be publishing documentation, or making
+    a configuration change to our infrastructure for a <https://nodejs.org>
+    problem. The expected resolution should be described in a comment on the
+    issue when it is moved to `TRIAGED`.
+    * ...: There are no explicit states for an issue as it is in process of
     getting resolved. Comments on the issue when someone is working on it are
     useful, as is assignment of the issue to a person who agrees to be
     responsible for following it through to resolution and disclosure.
-    - Once a fix is ready for release, the issue should be assigned to the
+    * Once a fix is ready for release, the issue should be assigned to the
     `Ready for release` team, and a comment added indicating the relevant PRs that
     need to be merged during the release process.
-5. `RESOLVED`: State for an issue that has had a fix published. Issues in this
-  state should be disclosed.
-6. ...: Final states for issues that we will not fix:
-    - `NOT-APPLICABLE`: We do not agree this a vulnerability. We can request
+3. `RESOLVED`: State for an issue that has had a fix published. Issues in this
+    state should be disclosed.
+4. ...: Final states for issues that we will not fix:
+    * `NOT-APPLICABLE`: We do not agree this a vulnerability. We can request
     that the reporter close it to preserve their H1 "reputation points".  If
     it is an issue, though not a vulnerability, we can suggest that it be
     reported to the Node.js issue tracker.
-    - `INFORMATIVE`: This means we agree that the report contains useful
+    * `INFORMATIVE`: This means we agree that the report contains useful
     information, but we don't intend to publish a fix. This might be because
     it isn't possible, or because its in an unsupported API or version. We
     can consider disclosing it if we  think the information should be
     publicized.
-    - `DUPLICATE`: The report is a duplicate of an already reported issue. It
+    * `DUPLICATE`: The report is a duplicate of an already reported issue. It
     should not need disclosure, because the original issue will be disclosed
     after it is resolved.
-    - `SPAM`: Self-explanatory (and rare).
-7. Disclosure: This not a HackerOne report state, but it is the final state
-  from our perspective. Disclosure should be considered once an issue is
-  closed. See the
-  [disclosure docs](https://docs.hackerone.com/programs/disclosure.html).
+    * `SPAM`: Self-explanatory (and rare).
+5. Disclosure: This not a HackerOne report state, but it is the final state
+    from our perspective. Disclosure should be considered once an issue is
+    closed. See the
+    [disclosure docs](https://docs.hackerone.com/programs/disclosure.html).

Streaming/Streaming-To-Youtube.md

@@ -13,6 +13,7 @@ Your YouTube Account must be a manager of the
 Ask the TSC Chair or foundation managers (Amanda Ennis, Brian Warner, Rachel
 Romoff) to make your account a manager. To add managers or verify an account
 is a manager:
+
 1. Go to <https://youtube.com>
 2. Click on the node.js icon on the right top.
 3. Select settings, select "Add or remove managers", select "Manage permissions"
@@ -50,33 +51,34 @@ The description should be a link to the meeting issue.
 
 You can edit title and description on YouTube at a later time if needed.
 
-![](youtube-stream-title-description.png)
+![YouTube Basic Info example text](youtube-stream-title-description.png)
 
 ### Share the meeting once you've gone live
 
 The meeting link should be `http://www.youtube.com/c/nodejs-foundation/live`.
 
 Send it in a tweet such as:
-```
+
+```text
 .@nodejs Technical Steering Committee meeting live now: http://www.youtube.com/c/nodejs-foundation/live
 ```
 
 Adjust the `Technical Steering Committee` part as necessary and remove the
 `.@nodejs` if tweeting from the official twitter account.
 
-![](youtube-stream-share.png)
+![YouTube Share input box](youtube-stream-share.png)
 
 ## Check stream status
 
 This should say online when you are streaming, and usually be green.
 
 However, it may turn yellow and issue a warning in a "stream health" section below. Since we usually stream with static images for the video, there will often be warnings that the video bitrate is low. This is a not a problem and should almost always be ignored.
 
-![](youtube-stream-status.png)
+![YouTube Stream Status showing Offline](youtube-stream-status.png)
 
 ## Check how many people are watching
 
-![](youtube-stream-analytics.png)
+![YouTube Analytics graph](youtube-stream-analytics.png)
 
 ## Moderate the chat and solicit questions
 

TSC-Charter.md

@@ -1,13 +1,13 @@
 # Technical Steering Committee (TSC) Charter
 
-## Section 1. Guiding Principle.
+## Section 1. Guiding Principle
 
 The Node.js project is part of the OpenJS Foundation which
 operates transparently, openly, collaboratively, and ethically.
 Project proposals, timelines, and status must not merely be
 open, but also easily visible to outsiders.
 
-## Section 2. Evolution of OpenJS Foundation Governance.
+## Section 2. Evolution of OpenJS Foundation Governance
 
 Most large, complex open source communities have both a business and a
 technical governance model. Technical leadership for the projects
@@ -26,7 +26,7 @@ additionally make amendments to the TSC charter at any time, though the
 CPC will not interfere with day-to-day discussions, votes or meetings
 of the TSC.
 
-## Section 3. Establishment of the TSC.
+## Section 3. Establishment of the TSC
 
 TSC memberships are not time-limited. There is no maximum size of the TSC.
 The size is expected to vary in order to ensure adequate coverage of important
@@ -68,7 +68,7 @@ participate in TSC discussions, *and* does not participate in TSC votes, the
 member shall be automatically removed from the TSC. The member may be invited
 to continue attending TSC meetings as an observer.
 
-## Section 4. Responsibilities of the TSC.
+## Section 4. Responsibilities of the TSC
 
 Subject to such policies as may be set by the CPC, the TSC is
 responsible for all technical development within the Node.js project,
@@ -87,7 +87,7 @@ projects.
 
 The TSC will define Node.js project’s release vehicles.
 
-## Section 5. Node.js Project Operations.
+## Section 5. Node.js Project Operations
 
 The TSC will establish and maintain a development process for the Node.js
 project. The development process will establish guidelines