diff --git a/docs/release-checklist.rst b/docs/release-checklist.rst
new file mode 100644
index 000000000..330b50687
--- /dev/null
+++ b/docs/release-checklist.rst
@@ -0,0 +1,151 @@
+.. -*- coding: utf-8-with-signature -*-
+
+=================
+Release Checklist
+=================
+
+meejah produced this list while making the 1.15.0 release. Many of the
+things in the `how_to_make_a_tahoe-lafs_release.org` document aren't
+relevant anymore. However, until we are sure that a "new release list"
+is correct and works, I don't just want to completely revise it.
+
+A major difference here is splitting into things that "any
+contributer" can do and things that contributers with possibly more
+access need to do.
+
+So, follow *this* list for 1.16.0 and if it seems complete, we should
+delete the older checklist after that.
+
+Any Contributor
+---------------
+
+Anyone who can create normal PRs should be able to complete this
+portion of the release process.
+
+
+Prepare for the Release
+```````````````````````
+
+The `master` branch should always be releasable. However, it is worth
+asking on appropriate channels (IRC, the mailing-list, Nuts and Bolts
+meetings) whether there are interesting changes that should be
+included (or NOT included) etc.
+
+- Create a ticket for the release in Trac
+- Ticket number needed in next section
+
+
+Create Branch and Apply Updates
+```````````````````````````````
+
+- Create a branch for release-candidates (e.g. `release-1.15.0.rc0`)
+- run `tox -e news` to produce a new NEWS.txt file (this does a commit)
+- create the news for the release
+  - newsfragments/<ticket number>.minor
+  - commit it
+- manually fix NEWS.txt
+  - proper title for lastest release (instead of "Release ...post1432")
+  - double-check date
+  - spot-check the release notes (these come from the newsfragments
+    files though so don't do heavy editing)
+  - commit these changes
+- update "relnotes.txt"
+  - update all mentions of 1.14.0 -> 1.15.0
+  - update "previous release" statement and date
+  - summarize major changes
+  - commit it
+- update "CREDITS"
+  - are there any new contributers in this release?
+  - one way: git log release-1.14.0.. | grep Author | sort | uniq
+  - commit it
+- update "docs/known_issues.rst" if appropriate
+- update "docs/INSTALL.rst" references to the new release
+- Push the branch to github
+- Create a (draft) PR; this should trigger CI (note that github
+  doesn't let you create a PR without some changes on the branch so
+  running + commiting the NEWS.txt file achieves that without changing
+  any code)
+- Confirm CI runs successfully on all platforms
+
+
+Create Release Candidate
+````````````````````````
+
+Before "officially" tagging any release, we will make a
+release-candidate available. So there will be at least 1.15.0rc0 (for
+example). If there are any problems, an rc1 or rc2 etc may also be
+released. Anyone can sign these releases (ideally they'd be signed
+"officially" as well, but it's better to get them out than to wait for
+that).
+
+Typically expert users will be the ones testing release candidates and
+they will need to evaluate which contributers' signatures they trust.
+
+- (all steps above are completed)
+- sign the release
+  - git tag -s -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A -m "release Tahoe-LAFS-1.15.0rc0" tahoe-lafs-1.15.0.rc0
+  - (replace the key-id above with your own)
+- build all code locally
+  - these should all pass:
+    - tox -e py27,codechecks,docs,integration
+  - these can fail (ideally they should not of course):
+    - tox -e deprecations,upcoming-deprecations
+- build tarballs
+  - tox -e tarballs
+  - confirm it at least exists:
+  - ls dist/ | grep 1.15.0rc0
+- inspect and test the tarballs
+  - install each in a fresh virtualenv
+  - run basic tests
+- when satisfied, sign the tarballs:
+  - gpg --pinentry=loopback --armor --sign dist/tahoe_lafs-1.15.0rc0-py2-none-any.whl
+  - gpg --pinentry=loopback --armor --sign dist/tahoe_lafs-1.15.0rc0.tar.bz2
+  - gpg --pinentry=loopback --armor --sign dist/tahoe_lafs-1.15.0rc0.tar.gz
+  - gpg --pinentry=loopback --armor --sign dist/tahoe_lafs-1.15.0rc0.zip
+
+
+Privileged Contributor
+-----------------------
+
+Steps in this portion require special access to keys or
+infrastructure. For example, **access to tahoe-lafs.org** to upload
+binaries or edit HTML.
+
+Hack Tahoe-LAFS
+```````````````
+
+Did anyone contribute a hack since the last release? If so, then
+https://tahoe-lafs.org/hacktahoelafs/ needs to be updated.
+
+
+Upload Artifacts
+````````````````
+
+Any release-candidate or actual release plus signature (.asc file)
+need to be uploaded to https://tahoe-lafs.org in ~source/downloads
+
+- how to do this?
+- who has access to do this?
+
+For the actual release, the tarball and signature files need to be
+uploaded to PyPI.
+
+- how to do this?
+- (original guide says only "twine upload dist/*")
+- who has access to do this?
+
+The actual release and signature also needs to be uploaded to GitHub
+so that it appears in "releases", e.g.:
+
+- https://github.com/tahoe-lafs/tahoe-lafs/releases/tag/tahoe-lafs-1.14.0
+
+
+Upload Dependencies
+```````````````````
+
+The original guide says, "upload wheels to
+https://tahoe-lafs.org/deps/" which seems to be all the wheels of all
+the dependencies. There are no instructions on how to collect these or
+where to put them on the tahoe-lafs.org machines.
+
+