Add a release checklist. Update contributor note

CONTRIBUTING.md

@@ -1,11 +1,8 @@
 # Welcome to the Project :)
-Now that some property, sanitization, crash and interleaving-exercising tests exist,
-it's safe to open this up for wider contribution! If you accidentally break something,
-there is a pretty good chance the tests will explode! So go wild!
 
 There are a ton of features and interesting directions this project can go in, and
 far more than I can implement on my own in a reasonable timespan. I want to scale out
-feature ownership to interested people. See the "plans" section on the main 
+feature ownership to interested people. See the "plans" section on the main
 [README](/README.md) for an overview.
 
 If you would like to help out, but don't know how, I probably have time to mentor you!
@@ -16,17 +13,14 @@ favors!
 Specifically, there are a few areas that I would love external help with:
 
 * better docs: whatever you find confusing!
-* performance tuning: this should theoretically be able to outperform rocksdb on reads,
-  and innodb on writes! let's get there! I usually run this to generate and view flamegraphs:
-  ```
-  cargo build -p stress2; hack/flamerun.sh ./target/debug/stress2 --duration 5; firefox ./flamegraph.svg
-  ```
+* performance tuning: this should obliterate leveldb and rocksdb performance.
+  if it doesn't, please submit a flamegraph and workload description!
 * a better C API: the current one is pretty unfriendly
 * generally any new kind of test that avoids biases inherent in the others
-* the deep end: prototyping a compiler plugin that allows specifiable blocks of code to be
-instrumented with pauses that cause interesting interleavings to be exhausted.
+* writing a SQL parser
 
 General considerations:
 
 * all PR's block on failing tests
 * all PR's block on breaking API changes (with the sole exception of the emerging C API)
+* don't be a jerk - here's our [code of conduct](./code-of-conduct.md)

RELEASE_CHECKLIST.md

@@ -0,0 +1,30 @@
+# Release Checklist
+
+This checklist must be completed before publishing a release of any kind.
+
+Over time, anything in this list that can be turned into an automated test should be, but
+there are still some big blind spots.
+
+## API stability
+
+- [ ] rust-flavored semver respected
+
+## Performance
+
+- [ ] micro-benchmark regressions should not happen unless newly discovered correctness criteria demands them
+- [ ] mixed point operation latency distribution should narrow over time
+- [ ] sequential operation average throughput should increase over time
+- [ ] workloads should pass TSAN and ASAN on macOS. Linux should additionally pass LSAN & MSAN.
+- [ ] workload write and space amplification thresholds should see no regressions
+
+## Concurrency Audit
+
+- [ ] any new `Guard` objects are dropped inside the rayon threadpool
+- [ ] no new EBR `Collector`s, as they destroy causality. These will be optimized in-bulk in the future.
+- [ ] no code assumes a recently read page pointer will remain unchanged (transactions may change this if reads are inline)
+- [ ] no calls to `rand::thread_rng` from a droppable function (anything in the SegmentAccountant)
+
+## Burn-In
+
+- [ ] fuzz tests should run at least 24 hours each with zero crashes
+- [ ] sequential and point workloads run at least 24 hours in constrained docker container without OOM / out of disk