Add SIG Node cherry-pick guide (#5703)

* Add SIG Node cherry-pick guide

* Update cherry-pick steward guide based on feedback

Author: ehashman

contributors/devel/sig-node/cherry-picks.md

@@ -0,0 +1,126 @@
+# SIG Node Cherry-Pick Management Process
+
+Kubernetes supports [multiple release versions] simultaneously. How do new
+fixes make it into earlier versions, when we only develop against one version
+at a time?
+
+We [cherry-pick] them!
+
+To assist the Release Team, a member of SIG Node can volunteer to oversee
+Node's cherry-picks. This guide is intended to document that person's
+responsibilities.
+
+[multiple release versions]: https://kubernetes.io/docs/setup/release/version-skew-policy/
+[cherry-pick]: /contributors/devel/sig-release/cherry-picks.md
+
+## Release timeline
+
+SIG Release regularly (on a ~monthly cadence) ships [patch releases]. Every
+release, the Release Team publishes a list of [target dates] with **cherry-pick
+deadlines**.
+
+SIG Node's responsibility is to ensure that all patches that we want
+cherry-picked to previous releases must be [triaged], prioritized, LGTM'd, and
+approved by the deadline.
+
+[patch releases]: https://github.com/kubernetes/sig-release/blob/master/release-engineering/versioning.md#patch-releases
+[target dates]: https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md#upcoming-monthly-releases
+[triaged]: triage.md
+
+## Monthly cherry-pick process
+
+Throughout the release cycle, merged bugfixes should be evaluated for inclusion
+as cherry-picks. Any bugs marked **critical-urgent** should be considered. Some
+**important-soon** bugs may also be considered if they are sufficiently
+contained and meet the criteria above.
+
+**Only** bug fixes should be considered for backports. Patches should be merged
+and soaked in CI for at least a week.
+
+To create a cherry-pick PR, you can use the `./hack/cherry_pick_pull.sh`
+script. Read through the [cherry pick documentation][cherry-pick] for details
+on that process.
+
+## Preparing the SIG's patches
+
+The week of the cherry-pick deadline, create a Slack thread ([example
+thread]) in the [#sig-node] channel to track the cherry-picks.
+
+To determine what fixes need to be cherry-picked, you can use the [SIG Node PR
+Board with the cherry-pick filter view]. Track each change considered for
+inclusion individually.
+
+Release branches are typically kept in sync. This means that bugfixes should be
+backported to all applicable supported branches. The [cherry pick
+schedule][target dates] will include a list of all supported releases and their
+end-of-life (EOL) dates.
+
+In the first comment in the Slack thread, track each patch and the status of
+backports to each branch. Some examples of what you might write are available
+below for reference. You can use the rest of the Slack thread for discussion.
+
+Typically, we will backport 2-3 patches per monthly cycle.
+
+[example thread]: https://kubernetes.slack.com/archives/C0BP8PW9G/p1617919799137500
+[#sig-node]: https://kubernetes.slack.com/messages/sig-node
+[SIG Node PR Board with the cherry-pick filter view]: https://github.com/orgs/kubernetes/projects/49?card_filter_query=label%3Ado-not-merge%2Fcherry-pick-not-approved
+
+### Example cherry-pick: all supported branches
+
+Consider the following PR to backport:
+https://github.com/kubernetes/kubernetes/pull/99600
+
+This fixes broken accounting in a beta feature that has been beta for the past
+three releases.
+
+Since it is a **critical-urgent** fix, it is eligible to be backported to all
+affected releases. During the 1.21 cycle, that means 1.18 through 1.20.
+
+Thus, our Slack update should look like the following:
+
+> Count pod overhead as an entity's resource usage https://github.com/kubernetes/kubernetes/pull/99600
+> - 1.18 https://github.com/kubernetes/kubernetes/pull/100039
+> - 1.19 https://github.com/kubernetes/kubernetes/pull/100038
+> - 1.20 https://github.com/kubernetes/kubernetes/pull/100037
+
+You can use this list and the Node Triage board to ensure all PRs have LGTMs
+and approvals, so they are ready for the Release Team by the cherry-pick
+deadline.
+
+### Example cherry-pick: limited release support
+
+Consider the following PR to backport:
+https://github.com/kubernetes/kubernetes/pull/98088
+
+This fixes an issue with an alpha feature introduced in 1.20, so it is only
+eligible to backport to 1.20 during the 1.21 cycle.
+
+In this case,
+
+- the fix only affects feature-gated code
+- the fix addresses a serious bug (repeatedly acquiring a lock unnecessarily)
+- the fix is small
+
+Hence, we included it in our backport.
+
+Thus, our Slack update should look like the following:
+
+> Fix repeatedly acquire the inhibit lock https://github.com/kubernetes/kubernetes/pull/98088
+> - 1.18 N/A, only affects 1.20+
+> - 1.19 N/A, only affects 1.20+
+> - 1.20 https://github.com/kubernetes/kubernetes/pull/99255
+
+### Example cherry-pick: rejected
+
+Consider the following PR to backport:
+https://github.com/kubernetes/kubernetes/pull/98376
+
+In this case,
+
+- the fix is a relatively involved refactor
+- the fix caused a known test regression
+- the regression fix is not being backported
+- the priority of the fix was **important-longterm**
+
+Hence, this would **not** be an appropriate patch to cherry-pick. SIG Node
+chose to close its cherry-pick PRs.