update some more sections

Author: KodrAus

src/SUMMARY.md

@@ -4,36 +4,38 @@
 
 [Getting started](./getting-started.md)
 
+[Reviewer checklist](./reviewer-checklist.md)
+
+---
+
+- [The feature lifecycle](./feature-lifecycle/summary.md)
+    - [Landing new features](./feature-lifecycle/new-unstable-features.md)
+    - [Using tracking issues](./feature-lifecycle/tracking-issues.md)
+    - [Stabilizing features](./feature-lifecycle/stabilization.md)
+    - [Deprecating features](./feature-lifecycle/deprecation.md)
+
+---
+
+- [Code considerations](./code-considerations/summary.md)
+    - [Design](./code-considerations/design/summary.md)
+        - [Public APIs](./code-considerations/design/public-apis.md)
+    - [Breaking changes](./code-considerations/breaking-changes/summary.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)
+        - [Drop and `#[may_dangle]`](./code-considerations/safety-and-soundness/may-dangle.md)
+        - [`std::mem` and exclusive references](./code-considerations/safety-and-soundness/mem-and-exclusive-refs.md)
+    - [Using unstable language features](./code-considerations/using-unstable-lang/summary.md)
+        - [Const generics](./code-considerations/using-unstable-lang/const-generics.md)
+        - [Specialization](./code-considerations/using-unstable-lang/specialization.md)
+    - [Performance](./code-considerations/performance/summary.md)
+        - [When to `#[inline]`](./code-considerations/performance/inline.md)
+
 ---
 
-# The feature lifecycle
-
-- [Landing new features](./feature-lifecycle/new-unstable-features.md)
-- [Using tracking issues](./feature-lifecycle/tracking-issues.md)
-- [Stabilizing features](./feature-lifecycle/stabilization.md)
-- [Deprecating features](./feature-lifecycle/deprecation.md)
-
-# Code considerations
-
-- [Reviewer checklist](./code-considerations/reviewer-checklist.md)
-- [Design](./code-considerations/design/summary.md)
-    - [Public APIs](./code-considerations/design/public-apis.md)
-- [Breaking changes](./code-considerations/breaking-changes/summary.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)
-    - [Drop and `#[may_dangle]`](./code-considerations/safety-and-soundness/may-dangle.md)
-    - [`std::mem` and exclusive references](./code-considerations/safety-and-soundness/mem-and-exclusive-refs.md)
-- [Using unstable language features](./code-considerations/using-unstable-lang/summary.md)
-    - [Const generics](./code-considerations/using-unstable-lang/const-generics.md)
-    - [Specialization](./code-considerations/using-unstable-lang/specialization.md)
-- [Performance](./code-considerations/performance/summary.md)
-    - [When to `#[inline]`](./code-considerations/performance/inline.md)
-
-# Tools and bots
-
-- [`@bors`](./tools-and-bots/bors.md)
-- [`@rust-timer`](./tools-and-bots/timer.md)
-- [`@craterbot`](./tools-and-bots/crater.md)
+- [Tools and bots](./tools-and-bots/summary.md)
+    - [`@bors`](./tools-and-bots/bors.md)
+    - [`@rust-timer`](./tools-and-bots/timer.md)
+    - [`@craterbot`](./tools-and-bots/crater.md)

src/code-considerations/reviewer-checklist.md

@@ -38,4 +38,4 @@ struct OptionCell<T> {
 
 ## For reviewers
 
-If there's a manual `Drop` implementation, consider whether `#[may_dangle]` is appropriate. If it is, make sure there's a `PhantomData<T>` too either through `Unique<T>` or manually.
+If there's a manual `Drop` implementation, consider whether `#[may_dangle]` is appropriate. If it is, make sure there's a `PhantomData<T>` too either through `Unique<T>` or as a field directly.

src/code-considerations/safety-and-soundness/may-dangle.md

@@ -9,3 +9,5 @@ The rules around what's sound and what's not can be subtle. See the [Unsafe Code
 ## For reviewers
 
 Look out for any unsafe blocks. If they're optimizations consider whether they're actually necessary. If the unsafe code is necessary then always feel free to ping somebody to help review it.
+
+Look at the level of test coverage for the new unsafe code. Tests do catch bugs!

src/code-considerations/safety-and-soundness/summary.md

@@ -0,0 +1,11 @@
+# Code considerations
+
+Code considerations capture our experiences working on the standard library for all contributors. If you come across something new or unexpected then a code consideration is a great place to record it. Then other contributors and reviewers can find it by searching the guide.
+
+## How to write a code consideration
+
+Code considerations are a bit like guidelines. They should try make concrete recommendations that reviewers and contributors can refer to in discussions. A link to a real case where this was discussed or tripped us up is good to include.
+
+Code considerations should also try include a _For reviewers_ section. These can call out specific things to look out for in reviews that could suggest the consideration applies. They can also include advice on how to apply it.
+
+It's more important that we capture these experiences _somehow_ though, so don't be afraid to drop some sketchy notes in and debate the details later!

src/code-considerations/summary.md

@@ -0,0 +1,3 @@
+# The feature lifecycle
+
+**Status:** Stub

src/feature-lifecycle/summary.md

@@ -0,0 +1,51 @@
+# Reviewer checklist
+
+**Status:** Stub
+
+Check the [getting started](./getting-started.md) guide for an introduction to developing in the standard library.
+
+If you'd like to reassign the PR, you can:
+
+```
+r? @user
+```
+
+## Before you review
+
+- [ ] Is this a [stabilization](./feature-lifecycle/stabilization.md) or [deprecation](./feature-lifecycle/deprecation.md)?
+    - [ ] Make sure there's a completed FCP somewhere for it.
+    - [ ] Ping `@rust-lang/libs` for input.
+
+## As you review
+
+Look out for code considerations:
+
+- [ ] [Design](./code-considerations/design/summary.md)
+- [ ] [Breaking changes](./code-considerations/breaking-changes/summary.md)
+- [ ] [Safety and soundness](./code-considerations/safety-and-soundness/summary.md)
+- [ ] [Use of unstable language features](./code-considerations/using-unstable-lang/summary.md)
+- [ ] [Performance](./code-considerations/performance/summary.md)
+
+## Before you merge
+
+- [ ] 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/new-unstable-features.md)?
+    - [ ] Create a [tracking issue](./feature-lifecycle/tracking-issues.md).
+    - [ ] Update the `#[unstable]` attributes to point to it.
+
+## When you're ready
+
+Use [`@bors`](./tools-and-bots/bors.md) to merge the pull request.
+
+To roll up:
+
+```
+@bors r+ rollup
+```
+
+or just:
+
+```
+@bors r+
+```

src/reviewer-checklist.md

@@ -9,3 +9,7 @@ You can approve a PR with:
 ```
 @bors r+
 ```
+
+## Rolling up
+
+For Libs PRs, rolling up is usually fine, in particular if it's only a new unstable addition or if it only touches docs. See the [rollup guidelines](https://forge.rust-lang/org/compiler/reviews.md#rollups) for more details on when to rollup.

src/tools-and-bots/bors.md

@@ -0,0 +1,3 @@
+# Tools and bots
+
+**Status:** Stub