PR Review Comments Unresolvable By Owner of Review

[nrmancuso]

From the github documentation at https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews:

You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.

As a collaborator with triage permissions and maintainer of an open source project, I should be able to resolve my own review items even though I do not have write access to the repository. I can delete my own review items, edit them, etc., so it follows that I should be able to resolve my own review items.

Example of needing member with read/ write access to resolve items: checkstyle/checkstyle#10990 (review)

To me - having the ability to delete review items where there could be discussion from other contributors and organization members has the potential to be much more destructive than simply resolving my own review items.

[romani]

just a comment .... To make it even more weird:
Author of PR can resolve conversation created by reviewer with Triage permission in that repo, BUT reviewer can not.
But it is good practice to let author of review point to resolve it as confirmation that all is done and point can be collapsed.

[Vyom-Yadav]

Agreed such a feature would be really helpful. Unable to resolve review items on my own creates a lot of noise in the comments and it is difficult to navigate through the conversation. Many times there are multiple unresolved reviews that have been addressed and should be in the resolved state but require the intervention of someone with write access to the repo which makes reviewing tedious.

[ES-Alexander]

Per #187503, the interface provides a "Resolve" button in a couple of different places that raises a 401 error when clicked:

so to me this feels like a (confusing and frustrating) bug rather than an intentional permissions limitation. The documentation is correct for the UX (of who ends up being allowed to resolve threads), but is inconsistent with the UI (and some contributors with good reason to believe they should be able to resolve their own threads).