[AFNobody]

GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control.

This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.

[sytse]

What is the nr. 1 performance/ux/bugfix you would like to see?

BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...

[omeid2]

I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle. Don't pay attention to them. Just do your thing.

Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.

[ntenenz]

A pretty glaring example is this one (LDAP password stored in plaintext): https://gitlab.com/gitlab-org/gitlab-ce/issues/38066

We purchased a gitlab subscription but cannot obtain infosec approval (and thus cannot use it) due to this issue.

[tfha]

Merge request page load times. Sometimes it can take like 5s for a merge request page to load (and then another 5s for the comments), and that's noticeably more frustrating than github's snappy UI. 5s isn't world ending but it is obviously slow and frustrating.

[pornel]

Treat server responses taking over 100ms as failures and keep fixing that.

There isn't 1 thing that's wrong, it's the entire UI, every operation that feels like it has a lag. Using GitLab is like using an app via remote desktop. It's tiring.

[AFNobody]

I am not here to push any specific ticket. I just think GitLab should move in the direction of redirecting more resources to fixing the warts as a general policy decision.

Ultimately, I am not your customer and haven't been for a couple years so it is up to you.

[rqs]

I don't know about the performance and bugfix issues, but based on my experience with gitlab.com, I don't think it has a good UX design.

You see, there are many many best practices in the UX world, just like those in the programming world. And seems to me, GitLab is not following many of them.

For example, the width of the content area.

I've once read an article that trying to dig into that topic, and one opinion that article has brought up was that users eye should not move too far up and down and more importantly left to right. I deeply agreed with this because I found myself feel very tired after reading a width page.

The solution is of course to limit how width the content area is, according to many factors (front size for example).

Now if you look at the user's home (project list) page on the GitLab, you will found that the page and the list (which is the main content) has been designed to fill 100% width of the view point.

On the left side of the list, is the name and description of my projects, and on the right side is the counters + update date.

The information on both left and right side are significant, so I may have to scan it from time to time, and it's exhausting.

If you're thinking, "Oh it's just the user's home page, no big deal". No No No, the search result page is the same deal, same design language.

Now, if you take look GitHub, you will found that they're not only limited the width of their page, they've also limited the width of the project list by adding a sidebar on the page. Which makes me 10 times more comfortable when using it.

Also, since we're talking about project list already, let me also remind you that the front is also very important.

Currently on the project page, the project name text is bold'ed, and underneath it is the description text. Problem is that the size of both text is the same, which makes them muddled together when doing a quick eye scan. GitHub on the other hand, use white space, front size and color to differentiates those elements which makes their list far better.

I did a little re-design to the project list to clarify what I've meant.

Before: https://imgur.com/klrah5A

After: https://imgur.com/wcHBVCe

And these just two examples, there are many of them. So please GitLab, design your web interface better. I'm currently mainly use your product now and I don't want to have many struggle with it :)

[kevinykchan]

I agree. Our team test drove gitlab earlier this year (as in, moving all repos over and using it for a month). We were hoping to consolidate a suite of products into one unified dev hub. )sadly, we found the general clunkyness and slowness a deal breaker for us. Lots of clicks to perform actions, each click requiring a short wait. Many features that applies to single projects don't apply to groups. We felt the core features were still very unfinished, especially when working with multiple repos. We looked at the roadmap and decided to move on.

[zaarn]

You could look at other products too.

Gitea has been very close to core Github Features IMO and Gogs (the original fork) has some neat other features separate from Github.

There is also Bitbucket which does integrate neatly into JIRA in my experience.

There is a lot of choice, Gitlab is great if you need a "everything in one box" solution for every problem or demand you might encounter during development.

Other Git-Webapps solve other problems or problem spaces.

[sytse]

At GitLab we invested a lot of time on our JIRA integration and we released support for GitLab subgroups in JIRA Development panel yesterday.