1# Additional onboarding information 2 3## Labels 4 5### Subsystems 6 7* `lib/*.js` (`assert`, `buffer`, etc.) 8* `build` 9* `doc` 10* `lib / src` 11* `test` 12* `tools` 13 14More than one subsystem may be valid for any particular issue or pull request. 15 16### General 17 18* `confirmed-bug`: Bugs you have verified 19* `discuss`: Things that need larger discussion 20* `feature request`: Any issue that requests a new feature 21* `good first issue`: Issues suitable for newcomers to fix 22* `meta`: Governance, policies, procedures, etc. 23* `tsc-agenda`: Open issues and pull requests with this label will be added to 24 the Technical Steering Committee meeting agenda 25 26--- 27 28* `author-ready` - A pull request is _author ready_ when: 29 * There is a CI run in progress or completed. 30 * There is at least one Collaborator approval (or two TSC approvals for 31 semver-major PRs). 32 * There are no outstanding review comments. 33 34Please always add the `author ready` label to pull requests that qualify. 35Please always remove it again as soon as the conditions are not met anymore, 36such as if the CI run fails or a new outstanding review comment is posted. 37 38--- 39 40* `semver-{minor,major}` 41 * be conservative – that is, if a change has the remote *chance* of breaking 42 something, go for semver-major 43 * when adding a semver label, add a comment explaining why you're adding it 44 * minor vs. patch: roughly: "does it add a new method / does it add a new 45 section to the docs" 46 * major vs. everything else: run last versions tests against this version, if 47 they pass, **probably** minor or patch 48 49### LTS/version labels 50 51We use labels to keep track of which branches a commit should land on: 52 53* `dont-land-on-v?.x` 54 * For changes that do not apply to a certain release line 55 * Also used when the work of backporting a change outweighs the benefits 56* `land-on-v?.x` 57 * Used by releasers to mark a PR as scheduled for inclusion in an LTS release 58 * Applied to the original PR for clean cherry-picks, to the backport PR 59 otherwise 60* `backport-requested-v?.x` 61 * Used to indicate that a PR needs a manual backport to a branch in order to 62 land the changes on that branch 63 * Typically applied by a releaser when the PR does not apply cleanly or it 64 breaks the tests after applying 65 * Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x` 66* `backported-to-v?.x` 67 * Applied to PRs for which a backport PR has been merged 68* `lts-watch-v?.x` 69 * Applied to PRs which the LTS working group should consider including in a 70 LTS release 71 * Does not indicate that any specific action will be taken, but can be 72 effective as messaging to non-collaborators 73* `lts-agenda` 74 * For things that need discussion by the LTS working group 75 * (for example semver-minor changes that need or should go into an LTS 76 release) 77* `v?.x` 78 * Automatically applied to changes that do not target `master` but rather the 79 `v?.x-staging` branch 80 81Once a release line enters maintenance mode, the corresponding labels do not 82need to be attached anymore, as only important bugfixes will be included. 83 84### Other labels 85 86* Operating system labels 87 * `macos`, `windows`, `smartos`, `aix` 88 * No `linux` label because it is the implied default 89* Architecture labels 90 * `arm`, `mips`, `s390`, `ppc` 91 * No `x86{_64}` label because it is the implied default 92