Hacker News Reader

Comment by DanielDent | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com