working on features

Author: KodrAus

src/SUMMARY.md

@@ -8,13 +8,18 @@
 
 # The feature lifecycle
 
-- [Landing new features](./feature-lifecycle/landing-new-features.md)
+This section describes the processes around how standard library features are developed and stabilized.
+
+- [Landing a new feature](./feature-lifecycle/new-unstable-features.md)
 - [Tracking issues](./feature-lifecycle/tracking-issues.md)
-- [Stabilization](./feature-lifecycle/stabilization.md)
-- [Deprecation](./feature-lifecycle/deprecation.md)
+- [Working on an unstable feature](./feature-lifecycle/working-on-unstable-features.md)
+- [Stabilizing a feature](./feature-lifecycle/stabilization.md)
+- [Deprecating a feature](./feature-lifecycle/deprecation.md)
 
 # Code considerations
 
+This section includes things to keep in mind when writing and reviewing standard library code. Most topics are relevant for both contributors and reviewers.
+
 - [Reviewer checklist](./code-considerations/reviewer-checklist.md)
 - [Design](./code-considerations/design/summary.md)
     - [Public APIs](./code-considerations/design/public-apis.md)
@@ -34,6 +39,8 @@
 
 # Tools and bots
 
+This section lists tools and bots that support the development process on the standard library. Most can be interacted with through GitHub mentions.
+
 - [`@bors`](./tools-and-bots/bors.md)
 - [`@rust-timer`](./tools-and-bots/timer.md)
 - [`@craterbot`](./tools-and-bots/crater.md)

src/code-considerations/breaking-changes/new-trait-impls.md

@@ -2,6 +2,8 @@
 
 A lot of PRs to the standard library are adding new impls for already stable traits, which can break consumers in many weird and wonderful ways. The following sections gives some examples of breakage from new trait impls that may not be obvious just from the change made to the standard library.
 
+Also see [`#[fundamental]` types](./fundamental.md) for special considerations for types like `&T`, `&mut T`, `Box<T>`, and other core smart pointers.
+
 ## Inference breaks when a second generic impl is introduced
 
 Rust will use the fact that there's only a single impl for a generic trait during inference. This breaks once a second impl makes the type of that generic ambiguous. Say we have:

src/code-considerations/reviewer-checklist.md

@@ -30,7 +30,7 @@ Look out for code considerations:
 
 - [ ] Is the commit log tidy? Avoid merge commits, these can be squashed down.
 - [ ] Can this change be rolled up?
-- [ ] Is this a [new unstable feature](../feature-lifecycle/landing-new-features.md)?
+- [ ] Is this a [new unstable feature](../feature-lifecycle/new-unstable-features.md)?
     - [ ] Create a [tracking issue](../feature-lifecycle/tracking-issues.md).
     - [ ] Update the `#[unstable]` attributes to point to it.
 

src/feature-lifecycle/landing-new-features.md renamed to src/feature-lifecycle/new-unstable-features.md

@@ -1,4 +1,4 @@
-# New features
+# Landing a new features
 
 **Status:** Stub
 

src/feature-lifecycle/working-on-unstable-features.md

@@ -0,0 +1,7 @@
+# Working on an unstable feature
+
+**Status:** Stub
+
+The current state of an unstable feature should be outlined in its [tracking issue](./tracking-issues.md).
+
+If there's a change you'd like to make to an unstable feature, it can be discussed on the tracking issue first.

src/getting-started.md

@@ -4,6 +4,8 @@
 
 > 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…