Define a policy using draft PRs when waiting on specific approvals

[handrews]

We've had some understandable confusion on when PRs get merged, as we came up with some exceptions to the "2 TSC approvals" rule in TDC calls. But not everyone is at every TDC call, nor can everyone be expected to remember everything that came up. So we should put PRs into draft, even if they are otherwise ready for merging, if we want to wait for a specific approval.

Just filing this b/c I don't have time to try to update DEVELOPMENT.md but we should do that at some point.

[handrews]

Another option is that we could define a minimum time for non-trivial PRs to remain open. (An examle of a trivial PR would be #3804, although we could use labels if we want to avoid vague heuristics).

[karenetheridge]

"in draft" and "waiting for specific approval" seem contradictory to me. Is there a specific label that could be used here? Or assign the review to the tsc team? (Is there a merge policy that could be set up to require N reviews from that team before it can be merged, without getting in the way of other PRs that have a different merge policy?)

[lornajane]

I think we have two things here:

• we should probably set the system to required two reviews
• sometimes we're looking for feedback from someone in particular

Draft is fair enough if the author does not believe that the PR can currently be merged (pending more changes, someone particular to review it, something else).