|
80 | 80 | review comments explicitly ask the author to address something before \ |
81 | 81 | merge. (Note: a *commit* by an approver does not count here — that's \ |
82 | 82 | an approver pushing a fix, not asking the author for something.) |
83 | | - 3. APPROVER — Otherwise, an APPROVER should act next. This includes: \ |
| 83 | + 3. AUTHOR (status-only response) — If an approver previously asked for \ |
| 84 | +concrete code changes (compilation fixes, tests, additional work, \ |
| 85 | +addressing review comments) and the author's latest activity is only a \ |
| 86 | +status update ("still working on this", "WIP", "will address soon", \ |
| 87 | +"ping", asking another clarifying question without delivering the \ |
| 88 | +requested changes, etc.) without any commits that actually deliver the \ |
| 89 | +requested work, the AUTHOR should still act next. The ball returns to \ |
| 90 | +the approver only when the author posts commits, a review reply with \ |
| 91 | +substantive content addressing the request, or otherwise indicates the \ |
| 92 | +requested changes are ready for re-review. |
| 93 | + 4. APPROVER — Otherwise, an APPROVER should act next. This includes: \ |
84 | 94 | fresh PRs with no reviews yet; PRs where the author has posted the \ |
85 | 95 | latest substantive event (comment, review, or commit) addressing \ |
86 | 96 | prior approver feedback; and PRs where an approver pushed the \ |
|
0 commit comments