I feel as though some of the recent UI changes were cosmetic and degraded the experience. I was especially unhappy about the sidebar being pushed into a hamburger menu (which can be pinned open, mind you).

I'd really like for UI updates in the future not to be jarring and seemingly pointless. I really liked the UI right before the overhaul, only minor tweaks seemed truly necessary. Many of the tweaks I would have suggested before have come through; such as putting profile information and notifications in the upper right hand corner. I'm glad about that.

Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.

Thanks for your feedback - we are always working on improving the UX/UI and appreciate your input! I know that large changes can feel jarring at first but we hope that in the end, they help improve workflow and productivity.

The sidebar is a global navigation and not always necessary when interacting with page-specific content on the site. GitLab is very content heavy and by allowing the sidebar to be collapsed, it allows users to have more space on smaller screens to read/scan the information that they need. As you mentioned, the sidebar can be pinned so users can view the navigation all the time if they prefer, esp if they are using a larger screen.

If you have other examples of changes that you felt were pointless, I'd love to find out the reason for the change for you!

I also urge you to voice your opinion by making an issue for changes that you think would help improve the user experience. https://gitlab.com/gitlab-org/gitlab-ce/issues/new

I've asked some people that work on our UI to respond, but we're aware that we have some ways to go before it's really good and that the large changes that we're making can be painful at first.

> Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.

Could you elaborate on what kind of features we'd be required to add given your suggestion? What do we miss?

I just finished an evaluation of Gitlab for our company and I'm blown away by all the awesome little touches that are geared toward productivity (merge requests that can be merged to a second branch with two clicks? yes please!).

That said, I'm holding off for now because I'd love for it to replace both Github and our current ticketing system, and rather than doing two migrations, I'd rather wait a few months until you guys have fleshed that out and do it all at once. The issue boards on your roadmap look absolutely fantastic, but the true killer feature I'm waiting on is time tracking, which I'm hoping makes it in later this year. Get that in and I think you'll see people flock to Gitlab.

In that case you might want to track issues on the velocity analytics

- https://gitlab.com/gitlab-org/gitlab-ce/issues/18687 - https://gitlab.com/gitlab-org/gitlab-ce/issues/20608

If you have ideas to improve the current vision, don't hesitate to join the conversation!

Was over a year since I last used GitLab, and I wonder if the resource usage and response times of a self-hosted instance has improved? Back then we were 3 developers having roughly 20 repos. The memory usage was over 2GB when idle and response times were at best between 2-3 seconds.

Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features.

My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes.

[1] https://gitlab.com/gitlab-org/gitlab-ce/commits/master

They've done a lot of work on performance in the past year. I'd recommend taking it for another spin.

Not enough, apparently. That page takes 10.5s to load and fails several performance metrics.

https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitla...

I get 5.5s now when I re-run it (probably due to caching). We've been working incredibly hard to make it faster, we have to use it everyday, so we know exactly how annoying the lack of speed can be.

For example, take a look at the drop in response time in the middle of last month: http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07

We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application!

Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository).

Ceph issues are here: https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...

See my comment above, but in short: GitLab.com is not representative of a self-hosted GitLab instance.

GitLab.com is too slow. We're working on it here: https://gitlab.com/gitlab-com/infrastructure/issues/59

If you run your own instance of GitLab now, it will be fast. Since last year March we've grown from 9 to now 100 people, many of which dedicated to performance.

GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0].

[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59

Heroku offers automatic deploy on linked repos from GitHub. Do you plan to integrate with Heroku to offer similar feature?

I believe the ball lays with Heroku for this one, mostly, but we'd love to see that in GitLab of course.

However, you can already deploy from GitLab quite easily to Heroku, it just requires a single line in your CI config:

http://docs.gitlab.com/ce/ci/examples/test-and-deploy-ruby-a...

And with Heroku's beta support for Docker deployments, it's even easier.

Why do you offer hosted EE gitlab free? I mean I love it but that seems to run counter to keeping gitlab around. In fact there seems to be no way at all to pay for gitlab, without having to host a local install.

Most of the market revenue is concentrated in on-premises/single-tenant installations, also see https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-...

You can always use our hosted private GitLab service[1] if you really insist on giving us your money without the hassle of a local install :)

[1]: https://githost.io/

Why doesn't LFS support SSH authentication? It has been requested numerous times and has missed numerous milestones. I'm still not convinced it will hit 8.11. We desperately need LFS support, but we use one time tokens, so LFS Authentication over HTTPS just won't work for us. We are an EE customer and this future is way more useful than a UI redesign! https://gitlab.com/gitlab-org/gitlab-ce/issues/3589

Git-LFS is a github project, you'd be better off asking them. But yeah I share your exp. without SSH and with all its numerous bugs LFS is one of the worst pieces of software i've come across. We switched to using rsync for binaries/ large files etc.

We're planning to do this as soon as possible. I agree that it has taken a long time. We simply did not have the capacity with the people that are able to work on this, to build it earlier.

We now have strengthened the team that works on these issues. I'm seeing whether it's possible to ship this with 8.12 (due Sept 22nd).

Any ideas of supporting Mercurial, too?

For Mercurial check out RhodeCode which is also supporting some of unique Mercurial features like largefiles, phases, bookmarks.

Just to give you guys some credit: I've had the pleasure of working with RhodeCode on my previous job 2.5 years ago and it was an awesome experience. HG & Git support, full-text search, repo-specific access control, a nice gui, easy setup, etc. Unfortunately, most devs and sysadmins I talk to don't even know about your product, which is a real pity, as they all use the same inferior products and don't know what they are missing out on. Now i'm stuck with gitlab and bitbucket-server, which everyone thinks are great, but every time I log into them I silently cry out for rhodecode. Hope you guys are doing well.

Anything specific we can do at GitLab so you don't feel that way when using it?

@dvdgsng We're better than ever, thanks! I don't know if you heard, RhodeCode CE is now free and open source. Feel free to join our Slack: https://rhodecode.com/join

We'll be rolling out a major release next week, might be the right time to spread a word to colleagues ;)

Can you give any specific feedback about Bitbucket Server? What can we do better?

We're not planning to support Mercurial in the near future.

Is there any reason why Gitlab is not adding mercurial support? Git command line is a nightmare to work with.

Any hope to get improvements on the issue tracker?

We hope to ship Issue boards[1] this months, which will be a mayor improvement! But maybe you could be more specific to what you're missing? We'd love to hear your feedback!

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/17907

Issue boards is great, but this is far from what we would need, tbh. We need a bugtracker, not a scrum board.

Mostly, we need a way to defined custom fields to be able to triage, query and reassign automatically. Like for example components or platform. And labels are clearly not enough for that.