A PR “conversation” (comment on a line of code) can either be resolved or not resolved. Compare this to Azure DevOps which has: Active, Pending, Won’t Fix, Resolved and Closed.
In my previous team, a closed source app on AzDO, we used the process:
- New feedback automatically get the Active status
- If the dev doesn’t plan on fixing it, set the status to won’t fix
- If the dev commits the change locally, but has not pushed, set to Pending
- Once the dev pushes the commit, set to Resolved
- Anyone who disagrees that the feedback has been resolved satisfactorily (either code change not good enough, or a won’t fix comment should be fixed), set the status back to active
- The person who gave the original feedback can close the comment when the pushed commit meets expectations.
Particularly on large or complex PRs, this makes it very easy to track feedback that as it progresses through the stages of being fixed and approved. GitHub feels overly simplistic to me by comparison, and I feel like my ability to review PRs is less productive than when I was previously working in Azure DevOps. I know many people hated AzDO’s complexity (mainly around issue management, not PRs) and therefore like GitHub’s simplicity. But while GitHub’s issue management simplicity can be worked around by abusing large numbers of labels to work around the lack of custom field support, I don’t know how to work around the two state PR conversation and feel less productive because of it.
In my opinion, there should be at least 3 states so I can track a comment that needs to be worked on, a comment that the author has pushed a fix for and should be reviewed again, and a comment that both the PR author and feedback author agree is resolved. I’d really like a 4th state to track comments that I’ve commit locally and not yet pushed, but I can live without that.