doc: remove onboarding-extras

Migrate last bit of onboarding-extras content to collaborator-guide and
remove onboarding-extras.

PR-URL: nodejs#39252
Reviewed-By: Gireesh Punathil <[email protected]>
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: Beth Griggs <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>

.github/CODEOWNERS

@@ -22,7 +22,6 @@
 /doc/guides/contributing/pull-requests.md @nodejs/tsc
 /doc/guides/collaborator-guide.md @nodejs/tsc
 /doc/guides/offboarding.md @nodejs/tsc
-/doc/guides/onboarding-extras.md @nodejs/tsc
 
 # streams
 

doc/guides/collaborator-guide.md

@@ -831,6 +831,86 @@ When things need extra attention, are controversial, or `semver-major`:
 
 If you cannot find who to cc for a file, `git shortlog -n -s <file>` can help.
 
+## Labels
+
+### General labels
+
+* `confirmed-bug`: Bugs you have verified
+* `discuss`: Things that need larger discussion
+* `feature request`: Any issue that requests a new feature
+* `good first issue`: Issues suitable for newcomers to fix
+* `meta`: Governance, policies, procedures, etc.
+* `tsc-agenda`: Open issues and pull requests with this label will be added to
+  the Technical Steering Committee meeting agenda
+
+---
+
+* `author-ready` - A pull request is _author ready_ when:
+  * There is a CI run in progress or completed.
+  * There is at least one Collaborator approval (or two TSC approvals for
+    semver-major pull requests).
+  * There are no outstanding review comments.
+
+Please always add the `author ready` label to pull requests that qualify.
+Please always remove it again as soon as the conditions are not met anymore,
+such as if the CI run fails or a new outstanding review comment is posted.
+
+---
+
+* `semver-{minor,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
+
+### LTS/version labels
+
+We use labels to keep track of which branches a commit should land on:
+
+* `dont-land-on-v?.x`
+  * For changes that do not apply to a certain release line
+  * Also used when the work of backporting a change outweighs the benefits
+* `land-on-v?.x`
+  * Used by releasers to mark a pull request as scheduled for inclusion in an
+    LTS release
+  * Applied to the original pull request for clean cherry-picks, to the backport
+    pull request otherwise
+* `backport-requested-v?.x`
+  * Used to indicate that a pull request needs a manual backport to a branch in
+    order to land the changes on that branch
+  * Typically applied by a releaser when the pull request 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 pull requests for which a backport pull request has been merged
+* `lts-watch-v?.x`
+  * Applied to pull requests which the Release working group should consider
+    including in an LTS release
+  * Does not indicate that any specific action will be taken, but can be
+    effective as messaging to non-collaborators
+* `release-agenda`
+  * For things that need discussion by the Release working group
+  * (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
+
+Once a release line enters maintenance mode, the corresponding labels do not
+need to be attached anymore, as only important bugfixes will be included.
+
+### Other labels
+
+* Operating system labels
+  * `macos`, `windows`, `smartos`, `aix`
+  * No `linux` label because it is the implied default
+* Architecture labels
+  * `arm`, `mips`, `s390`, `ppc`
+  * No `x86{_64}` label because it is the implied default
+
 ["Merge Pull Request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github
 [Deprecation]: https://en.wikipedia.org/wiki/Deprecation
 [SECURITY.md]: https://github.com/nodejs/node/blob/HEAD/SECURITY.md

onboarding.md

@@ -81,7 +81,7 @@ The project has two venues for real-time discussion:
   * Be nice about closing issues! Let people know why, and that issues and PRs
     can be reopened if necessary
 
-* [**See "Labels"**](./doc/guides/onboarding-extras.md#labels)
+* See [Labels][].
   * There is [a bot](https://github.com/nodejs-github-bot/github-bot) that
     applies subsystem labels (for example, `doc`, `test`, `assert`, or `buffer`)
     so that we know what parts of the code base the pull request modifies. It is
@@ -239,6 +239,7 @@ needs to be pointed out separately during the onboarding.
   the [summit](https://github.com/nodejs/summit) repository for details.
 
 [Code of Conduct]: https://github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md
+[Labels]: doc/guides/collaborator-guide.md#labels
 [Landing Pull Requests]: doc/guides/collaborator-guide.md#landing-pull-requests
 [Publicizing or hiding organization membership]: https://help.github.com/articles/publicizing-or-hiding-organization-membership/
 [`author-ready`]: doc/guides/collaborator-guide.md#author-ready-pull-requests