3 ms·

It really really would. And it's a very good thing that their product allows you to self-host, because I have zero-confidence in their ability to properly oper

It really really would. And it's a very good thing that their product allows you to self-host, because I have zero-confidence in their ability to properly operate infrastructure. But the attention to detail/quality on the product itself is lacking too. Don't get me wrong, I love gitlab as a product, but they really don't seem to care about working on anything that doesn't let them check another box on a marketing feature sheet. A selection of some issue I've filed... Only took around a year to fix: https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 Then this issue lingered for about a year before being closed because a customer filed a similar issue a couple months after I did... that other issue is still open though, so maybe they'll get around to it eventually: https://gitlab.com/gitlab-org/gitlab-ce/issues/25535 https://gitlab.com/gitlab-org/gitlab-ce/issues/25535 Here's one from two years ago that's still open: https://gitlab.com/gitlab-org/gitlab-ce/issues/19846 https://gitlab.com/gitlab-org/gitlab-ce/issues/19846 It's possible that issue is actually fixed now. I don't know and I don't care anymore. Here another issue from 2 years ago: https://gitlab.com/gitlab-org/gitlab-ce/issues/19656 https://gitlab.com/gitlab-org/gitlab-ce/issues/19656 I filed that issue after a Gitlab person here on hacker news specifically invited feedback on UX/UI issues, and I had just spent a frustrating time trying to track down a runner. At some point I just stopped filing issues & started ignoring the issues I'd already filed. The times they decided to close issues because they'd been open a long time certainly didn't inspire me to waste any more time trying to help them improve the product. Closing & re-opening and re-tagging and doing everything but actually fixing the issue is not confidence inspiring. Gitlab is still a great product, but now when I run into things that might warrant opening an issue, I just find ways of dealing with them on my own.

sytse 8y ago
I wanted to give some context issue by issue. 1. We consider stopping an environment https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 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 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 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.
- DanielDent 8y ago
  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.
  - sytse 8y ago
    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 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 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.
  - matejlatin 8y ago
    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 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.
jramsay 8y ago
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 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.
apple4ever 8y ago
Ugh I hear you. I have been following this issue for nearly a year: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056 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.
- detaro 8y ago
  Also sad to see how reports about regressions appear to turn into "feature requests", that then are nice to have instead of important.
- jramsay 8y ago
  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 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.

sytse 8y ago

I wanted to give some context issue by issue. 1. We consider stopping an environment https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 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 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 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.

DanielDent 8y ago
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.
- sytse 8y ago
  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 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 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.
- matejlatin 8y ago
  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 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.

jramsay 8y ago

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 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.

apple4ever 8y ago

Ugh I hear you. I have been following this issue for nearly a year: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056 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.

detaro 8y ago
Also sad to see how reports about regressions appear to turn into "feature requests", that then are nice to have instead of important.
jramsay 8y ago
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 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.