Skip to content

Commit

Permalink
doc: remove onboarding-extras
Browse files Browse the repository at this point in the history
Migrate last bit of onboarding-extras content to collaborator-guide and
remove onboarding-extras.

PR-URL: #39252
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
  • Loading branch information
Trott authored and targos committed Sep 4, 2021
1 parent 6466faf commit f08e9d5
Show file tree
Hide file tree
Showing 4 changed files with 82 additions and 82 deletions.
1 change: 0 additions & 1 deletion .github/CODEOWNERS
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
80 changes: 80 additions & 0 deletions doc/guides/collaborator-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
80 changes: 0 additions & 80 deletions doc/guides/onboarding-extras.md

This file was deleted.

3 changes: 2 additions & 1 deletion onboarding.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down

0 comments on commit f08e9d5

Please sign in to comment.