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...
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.
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.
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.
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.
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.
I don't understand the attitude of people like you.
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.
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.
We purchased a gitlab subscription but cannot obtain infosec approval (and thus cannot use it) due to this issue.
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.
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.
Ultimately, I am not your customer and haven't been for a couple years so it is up to you.
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 :)
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.
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.
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 :)
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!