doc: describe labelling process for backports

Based on discussion from the first backporting team meeting.

PR-URL: https://github.com/nodejs/node/pull/12431
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>

1 files changed, 27 insertions, 4 deletions

diff --git a/doc/onboarding-extras.md b/doc/onboarding-extras.md
index d19a73091f..400b5ea406 100644
--- a/doc/onboarding-extras.md
+++ b/doc/onboarding-extras.md
@@ -80,6 +80,33 @@ Please use these when possible / appropriate
   git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test
   ```
 
+### 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
 
@@ -89,10 +116,6 @@ Please use these when possible / appropriate
 * Architecture labels
   * `arm`, `mips`, `s390`, `ppc`
   * No x86{_64}, since that is the implied default
-* `lts-agenda`, `lts-watch-v*`
-  * tag things that should be discussed to go into LTS or should go into a specific LTS branch
-  * (usually only semver-patch things)
-  * will come more naturally over time
 
 
 ## Updating Node.js from Upstream