Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab Direction

about.gitlab.com

Post reply on HN
Print view View original

11–20 of 137 posts

Re: GitLab Direction

#11

Post by davchana »

sytse wrote: post #7
omeid2 wrote: post #6

Earlier quoted context omitted.

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 eno…

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 20…

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

Re: GitLab Direction

#12

Post by sytse »

ntenenz wrote: post #10
sytse wrote: post #4

Earlier quoted context omitted.

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

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.

Re: GitLab Direction

#13

Post by rqs »

sytse wrote: post #4
AFNobody wrote: post #3

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.

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

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

Re: GitLab Direction

#14

Post by AFNobody »

sytse wrote: post #4
AFNobody wrote: post #3

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.

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

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.

Re: GitLab Direction

#15

Post by AFNobody »

omeid2 wrote: post #6
sytse wrote: post #4

Earlier quoted context omitted.

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

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 eno…

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.

Re: GitLab Direction

#16

Post by WhyDoPeople »

whitepoplar wrote: post #2

GitLab is like the average kid in class that everybody makes fun of for constantly asking questions, but the joke's on them because "a little bit of slope makes up for a lot of y-intercept." While GitLab may have warts, I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub.

Just curious, what specifically you mean by "surpass Github"? I mean this with no snarky intention. I'm just wondering what tasks Gitlab doesn't perform as well as Github for you; unless you were referring to the social awareness that Github has.

Re: GitLab Direction

#17

Post by omeid2 »

AFNobody wrote: post #15
omeid2 wrote: post #6

Earlier quoted context omitted.

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 eno…

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.

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.

Re: GitLab Direction

#18

Post by woolvalley »

omeid2 wrote: post #6
sytse wrote: post #4

Earlier quoted context omitted.

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

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 eno…

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

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

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.

Re: GitLab Direction

#19

Post by teraflop »

AFNobody wrote: post #15
omeid2 wrote: post #6

Earlier quoted context omitted.

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 eno…

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.

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.

Re: GitLab Direction

#20

Post by kevinykchan »

AFNobody wrote: post #3

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.

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.
Post reply on HN