Wait a bit more before requiring approving reviews

[choldgraf]

My feeling is that this repository is still evolving quite rapidly (eg the documentation). Can we hold off on requiring an approving review until we think the repo is in a more steady state, and then turn it on?

Also, we should discuss as a group whether we want to impose these kinds of restrictions on the repositories in the EBP org (eg a requirement that a person reviews the PR before it may be merged). It may be the right decision, but either way it should be a group decision.

[chrisjsewell]

Its probably me being a control freak, but I do feel its best to have a second pair of eyes at least take a cursory glance at PRs to sanity check them.
For example in #50 I just wanted to check you were happy with the added documentation, rather than you going it and re-editing it later.

[chrisjsewell]

I'll turn it off for now, but would like to re-instate it asap

[choldgraf]

I think it makes sense to adopt this behavior after we've moved past the initial "rapid prototyping and building stage" of myst. I think we are close to that point but there may still be some big-ish changes that will benefit from the fluidity of self-merging.

Once we think this is, say, "alpha 0.1" ready, then I agree we should either require PRs to have a review or simply adopt team practices that nobody is allowed to merge their own PR unless it is exceptional. (I have found it may be useful to make it more of a team practice than a github restriction, in the rare case that it is helpful to self merge, such as if there is a critical bug you want fixed right away)

[chrisjsewell]

Now is that time 😁