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.
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.
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.
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!!
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.
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.
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.
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.
It is blocking people from converting to paying customers because as soon as we see an issue like that we know it isn't viable because we'll get denied.
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.
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.
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.
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.
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 :)
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
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
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 :)
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.
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.