diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md
index 221f87a8..d12cde43 100644
--- a/docs/CHANGELOG.md
+++ b/docs/CHANGELOG.md
@@ -30,6 +30,8 @@ When releasing a new version:
 
 ## v0.6.0
 
+Version 0.6.0 includes some small features and bugfixes. Note that genqlient now requires Go 1.18 or higher, and is tested through Go 1.20.
+
 ### Breaking changes:
 
 - genqlient now requires Go 1.18 or higher.
@@ -80,7 +82,7 @@ Version 0.4.0 adds several new configuration options, as well as additional meth
 ### New features:
 
 - genqlient now generates getter methods for all fields, even those which do not implement a genqlient-generated interface; this can be useful for callers who wish to define their own interface and have several unrelated genqlient types which have the same fields implement it.
-- The new `struct_references` option automatically sets the `pointer` and `omitempty` options on fields of struct type; see the [`genqlient.yaml` documentation](docs/genqlient.yaml) for details.
+- The new `struct_references` option automatically sets the `pointer` and `omitempty` options on fields of struct type; see the [`genqlient.yaml` documentation](genqlient.yaml) for details.
 - genqlient config now accepts either a single or multiple files (or globs) for the `schema` and `operations` fields (previously it accepted only one `schema`, and required a list of `operations` files).
 - genqlient now looks for its config file as `[.]genqlient.y[a]ml` in any ancestor directory, if unspecified, rather than only as `genqlient.yaml` in the current directory.
 - The `typename` option can now be used on basic types (string, int, etc) as well as structs; this can be useful to have genqlient define new types like `type Language string` and use that type for specified fields.
diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md
index 4741613f..c4a845d6 100644
--- a/docs/CONTRIBUTING.md
+++ b/docs/CONTRIBUTING.md
@@ -53,6 +53,7 @@ We try to cut releases periodically. To make a release:
 - Scan PRs since the last release to check we didn't miss anything in the changelog.
 - Check if there are any regressions or major problems with new features we want to fix before cutting the release.
 - Decide the new version number. We do a minor version bump for anything with breaking changes or significant new features, otherwise it can be a patch version bump.
-- Add a new section to the changelog (see comments in the changelog for instructions).
+- Add a new section to the changelog for the release (see comments in the changelog for instructions), and add a brief summary of the release at the top.
 - Make a PR with the above. (Example: [#208](https://github.com/Khan/genqlient/pull/208).)
-- When it merges, tag it as the new release, e.g. `git checkout main && git pull && git tag v0.X.Y && git push origin v0.X.Y`.
+- After it merges, tag it as the new release, e.g. `git checkout main && git pull && git tag v0.X.Y && git push origin v0.X.Y`.
+- Then, create a release in github, either [on the web](https://github.com/Khan/genqlient/releases/new) or with `export VERSION=v0.6.0; gh release create $VERSION --latest --verify-tag --generate-notes --title $VERSION`. (TODO(benkraft): Figure out how to pull in the changelog we've already written instead!)