3 files changed, 70 insertions, 9 deletions
diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index a32bb10dad..af3805f38e 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -53,6 +53,12 @@ been merged upstream.
       (Version bumps apply to `maint`; anything touching the changelog should
       apply only to `main` or `release`.)
 
+      When updating the version, it will be on `maint` branches and so to
+      merge-forward, use `git merge -s ours`. For instance, if merging the
+      version change of `maint-0.4.5` into `maint-0.4.6`, do on `maint-0.4.6`
+      this command: `git merge -s ours maint-0.4.5`. And then you can proceed
+      with a git-merge-forward.
+
    2. For the ChangeLog and ReleaseNotes, you need to write a blurb at the top
       explaining a bit the release.
 
@@ -70,7 +76,7 @@ Steps are:
 
    1. Run `./build.sh` which will download everything you need, including the
       latest tarballs from the release CI, and auto-commit the signatures if
-      the checksum match. You will need to confim the commits.
+      the checksum match. You will need to confirm the commits.
 
    2. If all is good, `git push origin main` your signatures.
 
@@ -120,26 +126,38 @@ do the following:
    2. Merge upstream the artifacts from the `patches` job in the
       `Post-process` stage of the CI release pipeline.
 
+      Like step (2.1) above, the `-dev` version bump need to be done manually
+      with a `git merge -s ours`.
+
    3. Write and post the release announcement for the `forum.torproject.net`
       in the `News -> Tor Release Announcement` category.
 
       If possible, mention in which Tor Browser version (with dates) the
       release will be in. This usually only applies to the latest stable.
 
-   4. Inform `tor-talk@lists.torproject.org` with the releasing pointing to
+   4. Inform `tor-announce@lists.torproject.org` with the releasing pointing to
       the Forum. Append the ChangeLog there. We do this until we can automate
       such post from the forum directly.
 
-### New Stable
+   5. Update torproject.org website by submitting a MR to
+      https://gitlab.torproject.org/tpo/web/tpo
 
-   1. Create the `maint-x.y.z` and `release-x.y.z` branches and update the
-      `./scripts/git/git-list-tor-branches.sh` with the new version.
+      The `databags/versions.ini` file is the one to change with the newly
+      released version(s).
+
+### New Stable
 
-   2. Add the new version in `./scripts/ci/ci-driver.sh`.
+   1. Create the `maint-x.y.z` and `release-x.y.z` branches at the version
+      tag. Then update the `./scripts/git/git-list-tor-branches.sh` with the
+      new version.
 
-   3. Forward port the ChangeLog and ReleaseNotes into main branch. Remove any
-      change logs of stable releases in ReleaseNotes.
+   2. Update `./scripts/git/git-list-tor-branches.sh` and
+      `./scripts/ci/ci-driver.sh` with the new version in `maint-x.y.z` and
+      then merge forward into main. (If you haven't pushed remotely the new
+      branches, merge the local branch).
 
+   3. In `main`, bump version to the next series: `tor-x.y.0-alpha-dev` and
+      then tag it: `git tag -s tor-x.y.0-alpha-dev`
 
 ## Appendix: An alternative means to notify packagers
 
diff --git a/doc/HACKING/Rust.md b/doc/HACKING/Rust.md
new file mode 100644
index 0000000000..a52807e540
--- /dev/null
+++ b/doc/HACKING/Rust.md
@@ -0,0 +1,43 @@
+# Rust support in C Tor
+
+The [Arti project](https://gitlab.torproject.org/tpo/core/arti) is the team's
+ongoing effort to write a pure-Rust implementation of Tor.
+
+Arti is not yet feature complete but it's in active development. That's where
+you want to go if you're interested in Tor and Rust together.
+
+This document describes something with niche interest: the C implementation of
+Tor can expose Rust crates which are used for internal testing, benchmarking,
+comparison, fuzzing, and so on. This could be useful for comparing the C
+implementation against new Rust implementations, or for simply using Rust
+tooling for writing tests against C.
+
+## Crates
+
+Right now we are only using this mechanism for one crate:
+
+- `tor-c-equix` -- Wraps the `src/ext/equix` module,
+  containing Equi-X and HashX algorithms.
+
+## Stability
+
+This is not a stable API and we have no plans to develop a stable Rust interface
+to the C implementation of Tor.
+
+## Files
+
+We use only a few of the standard Rust file types in order to build our
+wrapper crates. Here's a summary:
+
+- `Cargo.toml` in the repository root defines a Cargo *workspace*. It will
+  list all subdirectories that contain crates with their own `Cargo.toml`.
+- A per-crate `Cargo.toml` defines metadata and dependencies. These crates
+  should all be marked `publish = false`.
+- `build.rs` implements a simple build system that does not interact with
+  autotools. It uses the `cc` and `bindgen` crates to get from `.c`/`.h`
+  files to a static library and matching auto-generated bindings. Prefer to
+  include bindgen wrapper headers inline within `build.rs` instead of adding
+  `.h` files that are only used by the Rust bindings.
+- `lib.rs` publishes the low-level `ffi` interface produced with `cc` and
+  `bindgen`. This is also where we can add any wrappers or additions we want
+  for making the Rust API more convenient.
diff --git a/doc/HACKING/WritingTests.md b/doc/HACKING/WritingTests.md
index 129b79a854..463a4ad4af 100644
--- a/doc/HACKING/WritingTests.md
+++ b/doc/HACKING/WritingTests.md
@@ -336,7 +336,7 @@ glass-box one is one you implement while looking at how the function is
 implemented.
 
 In either case, make sure to consider common cases *and* edge cases; success
-cases and failure csaes.
+cases and failure cases.
 
 For example, consider testing this function: