One observation I have here is that it’s quite easy for PRs to “get lost in the shuffle”. If someone doesn’t happen to review it and give necessary feedback or if the author forgets about it for a while, it’s very easy for it to fall by the wayside. A way to address this would be to have a state machine for PRs that is partially automated and partially manual with clear roles. Here’s my attempt to write down such a state machine. This only covers PRs from non-committers since committers can shepherd their own PRs and my impression is that we do not have a problem with committer PRs languishing.
initial state
- automated:
- top GitHub-suggested reviewer is automatically assigned
- any maintainer can reassign at any point in this process
- transitions:
-
pr review
label automatically added
-
pr review
- manual:
- assignee will be pinged until they review
- assignee’s review is definitive
- transitions:
- PR merged by any maintainer (done)
- PR closed by any maintainer =>
rejected
- PR review request changes =>
changes needed
- PR review accept =>
accepted
- PR closed by author =>
abandoned
changes needed
- manual:
- author will be pinged until they close or request review
- transitions:
- new changes pushed, “please review” commented =>
pr review
- PR merged by any maintainer (done)
- PR closed by any maintainer =>
rejected
- PR review request changes =>
changes needed
- PR review accept =>
accepted
- PR closed by author =>
abandoned
- new changes pushed, “please review” commented =>
accepted
- automated
- waits until all CI actions are finished
- transitions:
- CI passed, no conflicts => auto merge (done)
- CI passed, conflicts =>
changes needed
- CI failed =>
ci review
- PR closed by author =>
abandoned
ci review
- manual:
- assignee will be pinged until they review
- assignee’s review is definitive
- transitions:
- PR merged by any maintainer (done)
- PR closed by any maintainer =>
rejected
- PR review request changes =>
changed needed
- CI restarted =>
accepted
- PR closed by author =>
abandoned