[hunter23]

Agreed - our company moved to Gitlab about the same time (2.5 years ago) and it's very clear from their updates that their focus has splintered in different directions. Our company has recently moved to more Microsoft products so I am pushing our CTO to move to Github.

If the CEO is following this, please improve basic user stories like:

* As a user, I want to easily know who has approved my merge request. Note the word "easily". The UI lists the people who did not approve next to label "Approved" and the people who did approve next to the label "Approved by". Makes absolutely no sense

* As a user, I want to see all the merge requests that I need to review because I am listed as an approved (it boggles my mind that this doesn't exist)

* As a user, I want to be notified by todos that only have any pending actions on them

* As a user, I want to disapprove a merge request

There are so many basic areas of the core product that are almost unusable. All of our engineers who have to regularly switch between github and gitlab prefer the github ui.

[merb]

Loading a Merge Request with 168 changes, basically breaks a 4cpu's 4gb instance on gitlab, so yes, "the most basic areas of the core product is almost unusable".

And while some integration is good... A lot of recent stuff is just "we try to grab the easy money"

[sytse]

Yep, load times of large merge requests was a big problem. In 11.1 we launched a refactor of merge requests to solve this https://about.gitlab.com/2018/07/22/gitlab-11-1-released/#me...

That got the time down for the worst case we measure from 15 seconds to 3 seconds, see https://news.ycombinator.com/item?id=17671300

[merb]

we are on 11.1 and it takes way more than 3 seconds (or even 15 seconds) (Request takes around 7 seconds and parsing it, and parsing it takes 10 seconds).

(P.S.: I also have the same source in gitea of a way less powerful instance which basically renders the whole thing in way less than 1 second.)

[victorwu]

--- As a user, I want to be notified by todos that only have any pending actions on them ---

Can you explain further what you mean by "pending actions on them"? We are working to simplify and streamline our notifications and todos in GitLab. In particular, the current thinking is that they are very similar. A "notification" is an email, and a "todo" is a something that GitLab calls your attention to in the Web UI to take action on. So mechanically, they are very similar and we would like to harmonize them.

Our latest discussion is in https://gitlab.com/gitlab-org/gitlab-ce/issues/48787.

[hunter23]

If I have a merge request where I am added as an approver and that code is merged in, then I don't want it to show up on my todos. A merge request has a specified amount of approvals required and when that threshold is hit and the code is merged, there is no work to be done. It is no longer a todo but a done. Unfortunately todos doesn't work this way and become useless for senior members who get listed as approvals for many merge requests.

In terms of combining them with notifications, I agree. I just need a web place to see all the "pending" action items I need to work on. A web notification feature should be the place to see all the pending notifications left for me (similar to how it would work on email except you can't expire emails).

[jramsay]

Thanks for taking the time to share your feedback. I'm the Product Manager responsible for merge requests. Approvals are such an important part of merge requests, and we are working to make them better.

We've improved a number of confusing approval widget states in GitLab 11.2 (https://gitlab.com/gitlab-org/gitlab-ee/issues/5439) which will ship later this month in and the ability to filter merge requests by approver is in development by a community member (https://gitlab.com/gitlab-org/gitlab-ee/issues/1951).

This is just the beginning though – code reviews and approvals are at the heart of the daily workflows of writing software and we'll be continuing to make them even better. I'm particularly excited about more structured code reviews with batch comments in 11.3 (https://gitlab.com/gitlab-org/gitlab-ee/issues/1984), better navigation between files in merge request diffs with a file tree in 11.4 (https://gitlab.com/gitlab-org/gitlab-ce/issues/14249), and our first iteration of code owners (https://gitlab.com/gitlab-org/gitlab-ee/issues/5382) also in 11.4.

Thanks for the disapprove merge request idea. We're considering this idea in https://gitlab.com/gitlab-org/gitlab-ee/issues/761 where further feedback would be much appreciated, or on any other issue.

[hunter23]

Hi - thanks for responding!

I'd point out that if you look at issue 5439 the team itself was originally unaware of the high number of edge case states of the merge request and closed the issue prematurely. Having many code paths is a code smell so I'd suggest simplifying your UX and edge cases here.

Since you own the merge request flow, I would suggest looking at the page and all it's edge cases and seeing where you can simplify for the user. There is a dizzying large amount of info and CTAs presented to the user; it's pure information overload. Don't just measure yourself by how many features you ship but rather on how you communicate those features to your users. Simplicity is a powerful feature in itself.

Looking forward to batch comments.

The disapprove merge request is a feature available in Phabricator and other competitors so I would look to see how they've implemented it.