4 ms·
My biggest issue with Github code reviews is how broken the "Changes requested" state is. If I request changes, there's no easy way to see that changes have bee
by bilalq 4y ago
My biggest issue with Github code reviews is how broken the "Changes requested" state is. If I request changes, there's no easy way to see that changes have been addressed and are clear for me to look at again.
I end up using open unresolved comments as the basis for changes requested now. It's hard to filter for those though.
- metadaemon 4y agoAs long as someone re-requests reviews (clicks on the little refresh icon) it should show up again in your pull requests to review.
- bilalq 4y agoThat's still a pretty broken experience though. If I update a PR via the CLI, why do I have to fumble around on github.com's UI again? The next revision is already up!
- jameslao 4y agoI hear you. Crocodile has a couple features that try to address this. 1. More comment states. Comments start as "open". The workflow I had in mind was that once the author addresses it, they would mark it as "resolved". The reviewer can go to the comments view (in the meta section on the left nav) where they can filter to resolved comments. If it looks good, they can mark it as "closed" or "open" again if they want more changes. I have this as a suggested workflow in the docs. [1] 2. The iterations section in the left nav lets you compare any two iterations. You can use this to see what has changed since your last review. Crocodile even indicates which iteration your last review was on to make this easy. [1] https://www.crocodile.dev/docs#commenting https://www.crocodile.dev/docs#commenting