| HN Mirror

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 2886 days ago

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.

Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/

The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark.

GitLab as a company was born on Hacker News https://news.ycombinator.com/item?id=4428278 and although the tone these days feels like different I hope it is a bond for live.

Qwertie 2886 days ago

I just wanted to add that I have been absolutely loving gitlab. Signed up in 2014 and use it pretty much daily.

One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy.

Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped me get things working and write better code.

Thanks so much for commenting, awesome to hear you're loving GitLab.

We made a lot of performance improvements, I'm glad you're benefitting from them. On https://about.gitlab.com/handbook/engineering/performance/#p... you can see what we're measuring. The monitoring of our biggest merge request https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-sum... shows of our fixes regressed and we're looking into what is going wrong. Screenshot for people reading this in the future: https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-...

There is a lot more work to do and we'll keep shipping performance improvements in code and to our infrastructure. The tentative date for our migration to GCP is next weekend.

I'm so glad to hear that contributing code to GitLab was a favorite experience! Kudos to our merge request coaches who try to get every merge request over the finish line with a high quality.

The migration to GCP is now scheduled for August 11. See https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuT...

davchana 2886 days ago

I just want to let you know that I code just for hobby, super simplistic projects like notes app, javascrtipt utilities, personal blog on Jekyll etc, gitlab @ davchana, I absolutely love Gitlab, and have been using it since almost two years. Before it I always had to find a free hosting, with lot of shaddy banner ads or unreliable systems. Gitlab.com free edition has everything I wish for, & occassionally I read & wander in gitlab.com issues repo just to see & be amazed on new improvements being made. Being a completely remote company is a cherry on top.. Great Work!!

Thank you very much!

https://developers.google.com/web/fundamentals/performance/r...

woolvalley 2886 days ago

Performance is fairly concrete to measure, mostly as part of click responsiveness.

They can also measure it live in the website, the median response time of API calls and so on.

Github has said this: "We’re quite obsessed with performance. We want to make sure the site is always performant and continually fast. For a Rails app, github.com is a really, really quick site and we have a motto that “It’s not shipped until it’s fast.”" https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-n...

They can create a performance measurement team, assign tickets based on what they find and prioritize them as part of ticket management. If something is too slow, then maybe it's time to refactor the underlying architecture or subsystem thats making things slow.

https://gitlab.com/gitlab-org/gitlab-ce/issues/38066

When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits.

I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.

teraflop 2886 days ago

It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.

raesene9 2886 days ago

I'd agree that, depending on usage model, this isn't a major issue, in that if you symmetrically encrypt a password, you still need to store the key somewhere to do the decryption.

That said it is possible to improve the security of this kind of model, although there is a trade-off in availability. What can be done is that the decryption key (or a passphrase controlling access to it) is stored offline and manually input at application launch.

The downside is that if the application restarts it needs human intervention to be operational. the upside is that you reduce (but not eliminate) the risks of the credentials being compromised from that system.

And that is the requirement enforced by IT in many companies with security audits.

You clearly never worked at a large company with one-size fits all security directives such as "never store the password in plain text".

omeid2 2886 days ago

You want hardened enterprise features, you pay for it; or contribute it, it is open source.

I don't understand the attitude of people like you.

jmisavage 2886 days ago

They have both SaaS and self-hosting options which cost considerable amount of cash ($99/mo per user for the most expensive option) for any large scale deployment. They're earning plenty and they need to fix what is valuable to their customers.

omeid2 2886 days ago

What makes you think they're not listening to their paid customers and fixing their needs? Paid customers get a direct contact.

ntenenz 2886 days ago

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.

Thanks for mentioning this. I've noted your interest in the relevant issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183#not...

If you have not done so already please ask our support team if they have an alternative solution. I've heard of people dynamically loading secrets but I'm not sure it addresses your use case.

tfha 2886 days ago

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 2886 days ago

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.

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 2886 days ago

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 :)

svesselov 2886 days ago

Hi there!

Thanks so much for the feedback, the UX team here at GitLab is always looking for ways to improve the user experience. It looks like someone else in this thread mentioned that you can choose between a fluid and fixed layout depending upon your preference. Some prefer a fixed width and others hate wasted screen space. We try our best to accommodate everyone.

Given that, we agree that this can be improved. We have an issue here discussing page-width, https://gitlab.com/gitlab-org/design.gitlab.com/issues/47. As you can see, in many cases we have decided that we should reduce the width in order to improve readability. I will add a link to your comment in the issue as further data on our user's preferences.

Also, we opened an issue with your suggestions for the project list page. Feel free to jump in and add any more thoughts you have there, feedback is always welcome. Here is a link: https://gitlab.com/gitlab-org/gitlab-ce/issues/49504

Keep the suggestions coming!

kushalpandya 2886 days ago

Hi,

Thanks for your feedback around content width. Making GitLab accessible on all screen sizes is important to us given that there are many users out there using HD (720p) screens primarily. Our design indeed has fixed width portrait container enclosing the page body (with maximum size being 1200px) so here's how it looks on a large monitor at 100% zoom: https://i.imgur.com/lTqL6X8.png

Hence if the browser viewport width goes below 1200px, page body ends up taking full width. Although this screen resolution being still widely used, I've opened an issue to discuss this further here https://gitlab.com/gitlab-org/gitlab-ce/issues/49488

Feel free to add more details to the issue.

rqs 2886 days ago

Sigh

So, hi kushalpandya, jmiserez and svesselov (For some reason I cannot reply your comment)

Looks like you guys didn't understand what I just said: The problem is the UX design is NOT very good. I think you guys should re-think about how user will interact with your interface.

For example (since I discovered the 'fluid' setting): Even if a user have a super wide monitor, when the user turn on the fluid setting and maximized the browser, should they saw an interface like this: https://screenshotscdn.firefoxusercontent.com/images/324e117... ?

Also, from my point of view, 1200px is still too wide for that list. If you take look the version that I've modified, you will notice it's only about 400px wide, and with that width, I can scan every results on the page without moving my eyes too much.

The magic thing is, with 400px, YOU can also scan every results on the page without moving YOUR eyes too much, even your monitor is wider than mine. And THIS, my friend, is the so called compatibility. The goal here, is to provide the same level of user experience -- GOOD user experience, NOT to fill the whole width so the page look like the same in every resolutions.

Again, the key point here is NOT about just the width of the page, it's not a problem between 400px and 1200px and 100%, it's about how you guys think how users will feel about the UI -- Will user feel tired when using it? Can the UI effectively helping user to get what they want? etc.

If you have no idea, go checkout some list designs on https://dribbble.com/ (By the way, dribbble.com itself is very well designed, go learn from it)

Don't worry though, I'll keep using your product and patiently waiting for improvement :)

jmiserez 2886 days ago

There already is an option to set this, at /profile/preferences:

Layout width

> GitLab can be set up to use different widths depending on your liking. Choose between the fixed (max. 1200px) and the fluid (100%) application layout.

kevinykchan 2886 days ago

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 2886 days ago

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.

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