diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 8198c8e23f269e..77333a671a5582 100644 --- a/.github/CODEOWNERS +++ b/.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 diff --git a/doc/guides/collaborator-guide.md b/doc/guides/collaborator-guide.md index dae3b8579de07f..cdc6c6da1dbad3 100644 --- a/doc/guides/collaborator-guide.md +++ b/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 ` 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 diff --git a/doc/guides/onboarding-extras.md b/doc/guides/onboarding-extras.md deleted file mode 100644 index 79951a433926c6..00000000000000 --- a/doc/guides/onboarding-extras.md +++ /dev/null @@ -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 diff --git a/onboarding.md b/onboarding.md index d1eca3a4c40f79..52104b9fb26128 100644 --- a/onboarding.md +++ b/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