Cleanup the code

CONTRIBUTING.md

@@ -1,14 +1,11 @@
 # Contributing
 
-Thanks for taking a look. FastNN is meant to be read and edited, so every file
-is one idea and none of them are long. Most of what follows is about keeping it
-that way.
+FastNN is meant to be read and edited: every file is one idea and none are long.
+Most of this is about keeping it that way.
 
-If you want to work on something bigger than a bug fix, open an issue first so
-we can agree on the shape before you write it. Issues labelled
-`good first issue` are a decent place to start, and `help wanted` is for
-bigger work, mostly performance. Comment on an issue before you start on it
-so two people don't write the same fix.
+For anything bigger than a bug fix, open an issue first. `good first issue` is a
+good place to start, `help wanted` is for bigger work, mostly performance.
+Comment on an issue before you start so two people don't write the same fix.
 
 During Hacktoberfest the [pinned issue](https://github.com/CanReader/FastNN/issues/56)
 explains what gets the `hacktoberfest-accepted` label.
@@ -36,21 +33,18 @@ at that same toolkit. The [CUDA section of the README](README.md#cuda) has the
 details, including `FASTNN_NVCC_CCBIN` for when `nvcc` rejects your system
 compiler.
 
-Use `--release` for anything that trains, debug is around 50x slower.
+Use `--release` for anything that trains. Debug is around 50x slower.
 
 ## Pull requests
 
-1. Fork, then branch off `master`. Name the branch after what it does,
-   `fix/batchnorm-variance` or `feat/conv3d`.
-2. Keep one change per PR. A bug fix and a refactor are two PRs.
-3. Fill in the template. "How it was verified" matters more than anything else
-   in there, so be specific.
-4. CI has to be green before merge. PRs are squash merged, so the PR title
-   becomes the commit on `master`. Keep it short, lowercase, and imperative:
+1. Fork and branch off `master`, e.g. `fix/batchnorm-variance`.
+2. One change per PR. A bug fix and a refactor are two PRs.
+3. Fill in the template. Be specific about how you verified it.
+4. CI has to be green. PRs are squash merged, so the title becomes the commit
+   on `master`: short, lowercase, imperative, like
    `fix softmax for widths that are not a power of two`.
 
-`master` is protected. Nothing lands on it without a PR and a passing CI run,
-including my own changes.
+`master` is protected. Everything goes through a PR, including mine.
 
 ## What CI checks
 
@@ -64,13 +58,12 @@ including my own changes.
 | Package | `cargo package`, so the published crate builds |
 | CUDA build | compiles the kernels with nvcc and runs clippy with `--features cuda` |
 
-Hosted runners have no GPU. The CUDA job proves the kernels compile and link,
-but nothing in CI runs them. If you touch `cuda/`, run `cuda_parity` locally
-and paste the result in the PR. If you have no GPU, say so and I'll run it.
+Hosted runners have no GPU, so CI only checks that the kernels compile and
+link. If you touch `cuda/`, run `cuda_parity` locally and paste the result in
+the PR. No GPU? Say so and I'll run it.
 
 A nightly job reruns the suite in release on stable and beta and trains the
-small examples, so problems that only show up with optimizations still get
-caught.
+small examples.
 
 ## Code conventions
 
@@ -105,12 +98,12 @@ for an activation is in `tensor/ops/activation.rs` and its derivative is in
 5. If it has a CUDA kernel, declare it in `cuda/ffi.rs`, wrap it in
    `cuda/kernels.rs`, and add a case to `tests/cuda_parity.rs`.
 
-The README has a full worked example under "Extending it".
+The README has a worked example under "Extending".
 
 ## Writing a gradcheck case
 
 Gradcheck compares each backward rule against central finite differences of its
-own forward. Two things trip people up:
+own forward. Two things to watch:
 
 * **Keep values bounded.** Finite differences subtract two nearby losses. If the
   loss is in the thousands, `f32` loses most of its digits to cancellation and
@@ -141,15 +134,13 @@ git push origin v0.4.0
 ```
 
 The release workflow checks the tag against `Cargo.toml`, runs the suite in
-release, builds the example programs for Linux (x86_64, ARM64, and x86_64 with
-CUDA), macOS (Intel and Apple Silicon), and Windows, publishes to crates.io, and
-creates the GitHub release with the archives, a `SHA256SUMS` file, and notes
-from the merged PRs. Release notes are grouped by PR label, so label your PRs.
+release, builds the examples for Linux (x86_64, ARM64, x86_64 with CUDA), macOS
+(Intel and Apple Silicon) and Windows, publishes to crates.io, and creates the
+GitHub release with the archives, `SHA256SUMS` and notes from the merged PRs.
+Notes are grouped by PR label, so label your PRs.
 
-Any PR that touches `release.yml` runs the whole thing except the publish
-steps, so the pipeline gets tested before a real tag depends on it.
+A PR that touches `release.yml` runs everything except the publish steps.
 
 ## License
 
-By contributing you agree that your work is released under the MIT license,
-same as the rest of the project.
+Contributions are released under the MIT license, same as the project.