Update development practices

[dstansby]

This updates development practices to:

• Require that one review is required for all PRs. This is to prevent developers merging there own PRs, which I have been very guilty of in the past. Although it can be frustrating not getting a review, I think it's probably worth tipping the balance in favour of waiting and getting a review here.
• Require that new minor releases are announced for a week before happening. cc @jakirkham

[jhamman]

Suggested change

	know that a release is planned. At least a week's notice should be given for other
	know that a release is planned. In most cases, at least a week's notice should be given for other

[dstansby]

I'm reluctant to un-tighten the language here - I think for minor releases (as opposed to micro releases with bugfixes) a week's notice is reasonable?

[jhamman]

I find these sorts of black/white constraints to introduce unnecessary friction. We don't want to get into a place where a minor release needs to go out but someone objects to its release because the announcement was only 5 days prior. I'm looking for directional guidance here, not hard and fast rules.

[dstansby]

I think "should be given" already indicates that almost always it should be respected, but there's room in exceptional circumstances to bypass the reccomendation? At least that's the existing language in this document, and it's not prefaced by "in most cases" elsewhere.

[jhamman]

Thanks @dstansby for opening this up. A few other observations that we may want to address here or elsewhere:

• the release workflow described here is quite outdated. We should not need to be creating tags locally and pushing them to GitHub. There is an opportunity to move closer to what Zarr-Python does here.
• taking that further, it seems like we're missing a number of the core recommendations from SPEC 0008. I'm curious if folks think there are things we can take from this that would help avoid yesterday's situation in the future?

cc @zarr-developers/python-core-devs

---

A note about yesterday's release. It was a bit of a bummer to have a breaking release in numcodecs force a release in zarr-python. That said, it wasn't that big of a disruption and is something that we can hopefully use to motivate improvements in our process here. Much better to learn our lesson on relatively inconsequential mistakes than on big ones!

[d-v-b]

broadly speaking I think the dev tooling in numcodecs could use some love. see #697. I have been satisfied with everything we are doing over in zarr-python w.r.t. CI and the developer environment. Copying that to numcodecs wherever possible would probably be a good use of effort.