a few more updates

Author: KodrAus

src/SUMMARY.md

@@ -19,8 +19,8 @@
 - [Design](./code-considerations/design/summary.md)
     - [Public APIs](./code-considerations/design/public-apis.md)
 - [Breaking changes](./code-considerations/breaking-changes/summary.md)
-    - [Breaking behavior](./code-considerations/breaking-changes/behavior.md)
-    - [New trait impls](./code-considerations/breaking-changes/new-trait-impls.md)
+    - [Breakage from changing behavior](./code-considerations/breaking-changes/behavior.md)
+    - [Breakage from new trait impls](./code-considerations/breaking-changes/new-trait-impls.md)
     - [`#[fundamental]` types](./code-considerations/breaking-changes/fundamental.md)
 - [Safety and soundness](./code-considerations/safety-and-soundness/summary.md)
     - [Generics and unsafe](./code-considerations/safety-and-soundness/generics-and-unsafe.md)

src/code-considerations/design/summary.md

@@ -6,4 +6,4 @@ Most of the considerations in this guide are quality in some sense. This section
 
 ## For reviewers
 
-Think about how you would implement a feature and whether your approach would differ from what's being proposed. What trade-offs are being made? Is the weighting of those trade-offs the most appropriate? 
+Think about how you would implement a feature and whether your approach would differ from what's being proposed. What trade-offs are being made? Is the weighting of those trade-offs the most appropriate?

src/feature-lifecycle/new-unstable-features.md

@@ -4,6 +4,8 @@
 
 New unstable features can be added and approved without going through a Libs FCP. There should be some buy-in from Libs that a feature is desirable and likely to be stabilized at some point before landing though.
 
+If you're not sure, open an issue against `rust-lang/rust` first suggesting the feature before developing it.
+
 All public items in the standard library need a `#[stable]` or `#[unstable]` attribute on them. When a feature is first added, it gets a `#[unstable]` attribute.
 
 Before a new feature is merged, those `#[unstable]` attributes need to be linked to a [tracking issue](./tracking-issues.md).

src/feature-lifecycle/stabilization.md

@@ -2,11 +2,21 @@
 
 **Status:** Stub
 
-Feature stabilization involves replacing `#[unstable]` attributes for a feature with `#[stable]` ones.
+Feature stabilization involves adding `#[stable]` attributes. They may be introduced alongside new trait impls or replace existing `#[unstable]` attributes.
+
+Stabilization goes through the Libs FCP process, which occurs on the [tracking issue](./tracking-issues.md) for the feature.
 
 ## Before writing a PR to stabilize a feature
 
-Check to see if a FCP has completed on the [tracking issue](./tracking-issues.md). If not, either ping `@rust-lang/libs` or leave a comment asking about the status of the feature.
+Check to see if a FCP has completed first. If not, either ping `@rust-lang/libs` or leave a comment asking about the status of the feature.
+
+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
+
+- 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.
 
 ## When there's `const` involved
 

src/getting-started.md

@@ -2,22 +2,24 @@
 
 **Status:** Stub
 
-> Everything I wish I knew before somebody gave me `r+`
-
 Welcome to the standard library!
 
 This guide is an effort to capture some of the context needed to develop and maintain the Rust standard library. Its goal is to help members of the Libs team share the process and experience they bring to working on the standard library so other members can benefit. It’ll probably accumulate a lot of trivia that might also be interesting to members of the wider Rust community.
 
-## If you’re ever unsure…
+## Where to get help
+
+Maintaining the standard library can feel like a daunting responsibility!
 
-Maintaining the standard library can feel like a daunting responsibility! Through [`highfive`], the automated reviewer assignment, you’ll find yourself dropped into a lot of new contexts.
+Ping the `@rust-lang/libs-impl` or `@rust-lang/libs` teams on GitHub anytime.
 
-Ping the `@rust-lang/libs-impl` or `@rust-lang/libs` teams on GitHub anytime. We’re all here to help!
+You can also reach out in the [`t-libs` stream on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/).
 
 ## A tour of the standard library
 
 **Status:** Stub
 
+The standard library codebase lives in the [`rust-lang/rust`](https://github.com/rust-lang/rust) repository under the `/library` directory.
+
 The standard library is made up of three crates that exist in a loose hierarchy:
 
 - `core`: dependency free and makes minimal assumptions about the runtime environment.