mirror of
https://github.com/nodejs/node.git
synced 2024-11-21 10:59:27 +00:00
doc: remove onboarding-extras
Migrate last bit of onboarding-extras content to collaborator-guide and remove onboarding-extras. PR-URL: https://github.com/nodejs/node/pull/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>
This commit is contained in:
Rich Trott
parent
b31c6c91ec
commit
2fd687ae1f
1
.github/CODEOWNERS
vendored
1
.github/CODEOWNERS
vendored
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -1,80 +0,0 @@
|
||||
# Additional onboarding information
|
||||
|
||||
## Labels
|
||||
|
||||
### General
|
||||
|
||||
* `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 PRs).
|
||||
* 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 PR as scheduled for inclusion in an LTS release
|
||||
* 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
|
||||
* 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
|
||||
* `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)
|
||||
* `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
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user