Comment by sdfhbdf | Hacker News Reader

Comment by sdfhbdf | Hacker News Reader

Parent Full thread

Very welcome improvements in Code Review department. Really like the explicit Viewed checkbox (even though I noticed that the bolding in the sidebar with the file tree tried to solve the same problem) and really nice with the suggestions.

My two top wishlist leftover items in that regard are

1. Marking whether a comment requests changes or not. This is of course straight out of GitHub, but I think their flow better matches what I found to be happening a in a lot of changes. I see such states for a Code review of a MR: Changes approved, Reviewer requests changes, reviewer leaves feedback (like "nice implementation", "good refactor", "minor: maybe you can refactor this?"). The last one is the most blurry in the GitLab approach since the way we can solve it is by starting a comment thread that is not resolved and approving a MR at the same time but it feels clunky. Maybe they can take a page out of GitHub's book.

2. Personal slack notifications. I would love to have first-party support for the notification system around MR, MR Comments, Being assigned, pipeline failing that messages me privately on slack. Jira recently had a revamp in their slack app and all notification moved there and overall I welcomed these changes since the only other way it seems to be email which speaks for itself - limited interactivity and it's becoming less of a notification medium anyway. [1]

[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/17958

Hi! I'm the PM for Code Review at GitLab - thanks for all the feedback. The team really knocked it out of the park in 13.9 so it's great to see that being recognized.

> 1. Marking whether a comment requests changes or not. This is of course straight out of GitHub, but I think their flow better matches what I found to be happening a in a lot of changes. I see such states for a Code review of a MR: Changes approved, Reviewer requests changes, reviewer leaves feedback (like "nice implementation", "good refactor", "minor: maybe you can refactor this?"). The last one is the most blurry in the GitLab approach since the way we can solve it is by starting a comment thread that is not resolved and approving a MR at the same time but it feels clunky. Maybe they can take a page out of GitHub's book.

This is something we've been thinking about a lot and want to address. Right now our comments are pretty murky in that it's not clear what might be required. We'd like to add some kind of support here to make that clearer and you can see some issues in https://gitlab.com/groups/gitlab-org/-/epics/4349

We've also been thinking about this in the handoff part of the reviewer workflows (https://gitlab.com/groups/gitlab-org/-/epics/5074), as a way to signal what the expectation from the reviewer is once they've finished the review.

Stay tuned!

Thanks for the reply. Nice to see you guys are so appreciative of feedback. Thanks for linking the issue I will probably track it now since I was not able to find the nomenclature to find it before. I will probably ask our company account manager to point out that we would be interested in this since we do pay for your product in the end.

Whenever Code review surpasses the UX of GitHub, and i think they're close but just have different approaches to some stuff I think GH for Teams will have no advantage over GitLab. GitLab CI blows GitHub out of the water in my experience.

Is there a way to assign two people for a review? Currently I assign one and then switch when the first has finished their review.

Yes, you can have multiple reviewers.

+1 especially on 2. I somehow can't set up the email notifications to work properly in my work group (just notify me when stuff happens in repos that I am an explicit maintainer/or just notify changes on MR I am involved in), so I can't even use the email -> slack integration. Weirdly the global GitLab notification works for my personal needs like following an MR on GitLab's repo.

Reply on news.ycombinator.com