Ugh I hear you. I have been following this issue for nearly a year: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056

I cannot believe its not fixed it. They made the MR file view completely useless for us. It was a new "feature" that actually made things worse.

James (Product Manager at GitLab) here. I've just picked up merge requests and have seen lots of feedback across multiple issues related to navigating between diffs/files when reviewing a merge request, and I want to make it better too.

There have been a few different solutions proposed including adding a file tree to the merge request interface, so you can quickly see a full list of the files and how they relate to each other. There is a design discovery issue for adding a file tree to the merge request interface https://gitlab.com/gitlab-org/gitlab-ce/issues/49189 scheduled for the next release to work out the UX in more detail.

Would a file tree make reviewing a merge request easier for you? Thanks for the feedback, and would love to hear more here, or on the issue.

Also sad to see how reports about regressions appear to turn into "feature requests", that then are nice to have instead of important.

Thanks Daniel. I'm a Product Manger at GitLab. The relative submodule fix is scheduled as a Deliverable for 11.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/25535 – sorry it's taken so long.

Normally new duplicate issues are consolidated into the oldest issue, but since both issues had been open a while ago I kept the issue that had the most participants and discussion open.

I wanted to give some context issue by issue.

1. We consider stopping an environment https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 a new feature, not a bug.

2. Relative submodule links are planned for 11.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/37356

3. Not showing a retry option to logged out users https://gitlab.com/gitlab-org/gitlab-ce/issues/19846 is a good improvement but since very few logged out users will see this message we don't consider it a bug.

4. Showing the original project next to the runner IDs makes a lot of sense. As you can see in the issue we are no longer closing feature proposals due to inactivity.

If you find ways of dealing with above things on your own that involve modifying GitLab please consider contributing them back.

Your response only furthers my point: if it doesn't show up on a marketing feature sheet, Gitlab doesn't seem to care to devote any resources to it.

Adding new features is great, but making sure that the user experience around existing features is smooth/sensible/not frustrating is pretty important too.

The approach of shipping 80% solutions which take 20% of the effort probably got Gitlab to where it is today. But at some point the company is large enough and has enough resources that it's reasonable to expect that the difficult parts of the problem and the "polish" get addressed too.

We care about making sure GitLab is polished end to end. We hired a UX team and now have two UX researchers on staff to find the biggest problems and fix them. An example of the outcome of that research is the SSH key experience https://gitlab.com/gitlab-org/ux-research/issues/53 of which the improvements shipped in this release.

We balance new major features, performance improvements and bug fixes https://news.ycombinator.com/item?id=17588352 and polish.

The vision of GitLab of a single application for the whole DevOps lifecycle is large and even though we have 160 engineers (including support) we can't do it all.

So if there are people who are proficient in Ruby we would love for them to submit improvements and join the 2000 people who already contributed code to GitLab.

Hey, Matej here, I'm part of the UX team at GitLab. I understand that it can look like we don't spend much time polishing the user interfaces and experiences that much but I can assure that we do. We don't have a split in % on how much time we should spend polishing existing things but maybe it's something we should consider doing.

Just to give an example of a recent redesign of an existing feature that I was involved in, it can be found here: https://gitlab.com/gitlab-org/gitlab-ee/issues/6089

Our application covers the whole DevOps lifecycle which means it takes a lot of effort to upkeep existing and constantly ship new features, but we always strive to do our best.

Thanks for the feedback, I think it will trigger internal discussions on how much time we should spend polishing existing features and experiences.

Re "polishing", part of that might be treating complaints about experience getting worse differently than requests for improvements. E.g. from a different subthread here: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056 The report clearly is "this has been broken", but nothing in the issue suggests it being noticed as a regression and not just another potential for improvement, whereas the customer will remember "this worked, and they broke it".