Update stabilization documentation

src/feature-lifecycle/stabilization.md

@@ -1,6 +1,7 @@
 # Stabilizing features
 
-**Status:** Stub
+**Status:** Current
+**Last Updated:** 2022/03/03
 
 Feature stabilization involves adding `#[stable]` attributes. They may be introduced alongside new trait impls or replace existing `#[unstable]` attributes.
 
@@ -12,11 +13,11 @@ Check to see if a FCP has completed first. If not, either ping `@rust-lang/libs`
 
 This will save you from opening a stabilization PR and having it need regular rebasing while the FCP process runs its course.
 
-## Writing a stabilization PR
+## Partial Stabilizations
+
+When you only wish to stabilize a subset of an existing feature your first step should be to split the feature into multiple features, each with their own tracking issues.
 
-- Replace any `#[unstable]` attributes for the given feature with stable ones. The value of the `since` field is usually the current `nightly` version.
-- Remove any `#![feature()]` attributes that were previously required.
-- Submit a PR with a stabilization report.
+You can see an example of partially stabilizing a feature with tracking issues [#71146](https://github.com/rust-lang/rust/issues/71146) and [XXXXX]() with FCP and the associated implementation PR [XXXXX]().
 
 ## When there's `const` involved
 
@@ -25,3 +26,19 @@ Const functions can be stabilized in a PR that replaces `#[rustc_const_unstable]
 Check whether the function internally depends on other unstable `const` functions through `#[allow_internal_unstable]` attributes and consider how the function could be implemented if its internally unstable calls were removed. See the _Stability attributes_ page for more details on `#[allow_internal_unstable]`.
 
 Where `unsafe` and `const` is involved, e.g., for operations which are "unconst", that the const safety argument for the usage also be documented. That is, a `const fn` has additional determinism (e.g. run-time/compile-time results must correspond and the function's output only depends on its inputs...) restrictions that must be preserved, and those should be argued when `unsafe` is used.
+
+## Writing a stabilization PR
+
+To stabilize a feature, follow these steps:
+
+0. (Optional) For partial stabilizations, create a new tracking issue for either the subset being stabilized or the subset being left unstable as preferred. If you're unsure which way is best ask a libs-api team member.
+0. Ask a **@rust-lang/libs-api** member to start an FCP on the tracking issue and wait for the FCP to complete (with `disposition-merge`).
+0. Change `#[unstable(...)]` to `#[stable(since = "version")]`. `version` should be the *current nightly*, i.e. stable+2. You can see which version is the current nightly [on Forge](https://forge.rust-lang.org/#current-release-versions).
+0. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the compiler or tools, remove it from there as well.
+0. If applicable, change `#[rustc_const_unstable(...)]` to `#[rustc_const_stable(since = "version")]`.
+0. Open a PR against `rust-lang/rust`.
+   - Add the appropriate labels: `@rustbot modify labels: +T-libs-api`.
+   - Link to the tracking issue and say "Closes #XXXXX".
+
+You can see an example of stabilizing a feature with [tracking issue #81656 with FCP](https://github.com/rust-lang/rust/issues/81656) and the associated [implementation PR #84642](https://github.com/rust-lang/rust/pull/84642).
+