doc: update formatting to fit our 80 chars rule

This will also use a proper indentation as a couple of entries
had a extra indentation of two spaces.

PR-URL: https://github.com/nodejs/node/pull/17722
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>

1 files changed, 34 insertions, 16 deletions

diff --git a/doc/onboarding-extras.md b/doc/onboarding-extras.md
index 0da3b1b525..a010d8fef1 100644
--- a/doc/onboarding-extras.md
+++ b/doc/onboarding-extras.md
@@ -42,7 +42,8 @@
 | upgrading npm                         | @fishrock123, @MylesBorins                                            |
 | upgrading V8                          | @nodejs/v8, @nodejs/post-mortem                                       |
 
-When things need extra attention, are controversial, or `semver-major`: @nodejs/tsc
+When things need extra attention, are controversial, or `semver-major`:
+@nodejs/tsc
 
 If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
 
@@ -51,12 +52,14 @@ If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
 
 ### By Subsystem
 
-We generally sort issues by a concept of "subsystem" so that we know what part(s) of the codebase it touches.
+We generally sort issues by a concept of "subsystem" so that we know what
+part(s) of the codebase it touches.
 
 **Subsystems generally are**:
 
 * `lib/*.js`
-* `doc`, `build`, `tools`, `test`, `deps`, `lib / src` (special), and there may be others.
+* `doc`, `build`, `tools`, `test`, `deps`, `lib / src` (special), and there may
+  be others.
 * `meta` for anything non-code (process) related
 
 There may be more than one subsystem valid for any particular issue / PR.
@@ -74,13 +77,19 @@ Please use these when possible / appropriate
 --
 
 * `semver-{minor,major}`
-  * be conservative – that is, if a change has the remote *chance* of breaking something, go for semver-major
+  * be conservative – that is, if a change has the remote *chance* of breaking
+    something, go for semver-major
   * when adding a semver label, add a comment explaining why you're adding it
-  * minor vs. patch: roughly: "does it add a new method / does it add a new section to the docs"
-  * major vs. everything else: run last versions tests against this version, if they pass, **probably** minor or patch
-  * A breaking change helper ([full source](https://gist.github.com/chrisdickinson/ba532fa0e4e243fb7b44)):
+  * minor vs. patch: roughly: "does it add a new method / does it add a new
+    section to the docs"
+  * major vs. everything else: run last versions tests against this version, if
+    they pass, **probably** minor or patch
+  * A breaking change helper
+    ([full source](https://gist.github.com/chrisdickinson/ba532fa0e4e243fb7b44)):
   ```sh
-  git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test
+  SHOW=$(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')
+  git checkout $(git show -s --pretty='%T' $SHOW) -- test
+  make -j4 test
   ```
 
 ### LTS/Version labels
@@ -92,21 +101,28 @@ We use labels to keep track of which branches a commit should land on:
   * Also used when the work of backporting a change outweighs the benefits
 * `land-on-v?.x`
   * Used by releasers to mark a PR as scheduled for inclusion in an LTS release
-  * Applied to the original PR for clean cherry-picks, to the backport PR otherwise
+  * Applied to the original PR for clean cherry-picks, to the backport PR
+    otherwise
 * `backport-requested-v?.x`
-  * Used to indicate that a PR needs a manual backport to a branch in order to land the changes on that branch
-  * Typically applied by a releaser when the PR does not apply cleanly or it breaks the tests after applying
+  * Used to indicate that a PR needs a manual backport to a branch in order to
+    land the changes on that branch
+  * Typically applied by a releaser when the PR does not apply cleanly or it
+    breaks the tests after applying
   * Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x`
 * `backported-to-v?.x`
   * Applied to PRs for which a backport PR has been merged
 * `lts-watch-v?.x`
-  * Applied to PRs which the LTS working group should consider including in a LTS release
-  * Does not indicate that any specific action will be taken, but can be effective as messaging to non-collaborators
+  * Applied to PRs which the LTS working group should consider including in a
+    LTS release
+  * Does not indicate that any specific action will be taken, but can be
+    effective as messaging to non-collaborators
 * `lts-agenda`
   * For things that need discussion by the LTS working group
-  * (for example semver-minor changes that need or should go into an LTS release)
+  * (for example semver-minor changes that need or should go into an LTS
+    release)
 * `v?.x`
-  * Automatically applied to changes that do not target `master` but rather the `v?.x-staging` branch
+  * Automatically applied to changes that do not target `master` but rather the
+    `v?.x-staging` branch
 
 Once a release line enters maintenance mode, the corresponding labels do not
 need to be attached anymore, as only important bugfixes will be included.
@@ -126,6 +142,7 @@ need to be attached anymore, as only important bugfixes will be included.
 * `git remote add upstream git://github.com/nodejs/node.git`
 
 to update from nodejs/node:
+
 * `git checkout master`
 * `git remote update -p` OR `git fetch --all` (I prefer the former)
 * `git merge --ff-only upstream/master` (or `REMOTENAME/BRANCH`)
@@ -135,5 +152,6 @@ to update from nodejs/node:
 
 * commit often, out to your github fork (origin), open a PR
 * when making PRs make sure to spend time on the description:
-  * every moment you spend writing a good description quarters the amount of time it takes to understand your code.
+  * every moment you spend writing a good description quarters the amount of
+    time it takes to understand your code.
 * usually prefer to only squash at the *end* of your work, depends on the change