undefined | Better HN

0 pointssytse7y ago0 comments

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.

0 comments

4 comments · 1 top-level

DanielDent7y ago· 3 in thread

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.

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

matejlatin7y 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

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.

detaro7y ago

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

j / k navigate · click thread line to collapse