I haven't checked out v11 yet, but since it's not yet mentioned I assume the admin UX hasn't been addressed. Of all the tools I have admin on, Gitlab's admin UI

I haven't checked out v11 yet, but since it's not yet mentioned I assume the admin UX hasn't been addressed. Of all the tools I have admin on, Gitlab's admin UI (spread out across multiple sections) is perhaps the most sprawling and confusing. For example, there are two "repository" sections in each repo (one top level, one under settings) - in one you can perform repository admin such as branch management, and in another you can configure things like deploy keys. The groups/users/repo setup is another example of a clunky workflow - functional, but too many steps, and stitched together CRUD UIs. I get the feeling no product manager has sat down to address admin cohesively for a number of years, but rather that it has just grown organically. My other big wish for the product is better CI. Gitlab certainly makes Travis unnecessary, but it doesn't scratch the surface of the functionality that Jenkins provides via the plugin ecosystem. Yes Jenkins is janky (although can be made to look nice enough via themes) - but Gitlab doesn't even address parsing xunit results and displaying trends in a project centric reporting location (https://gitlab.com/gitlab-org/gitlab-ce/issues/17081 https://gitlab.com/gitlab-org/gitlab-ce/issues/17081), instead steering you towards build centric "pages". Get the reporting built out (and also allow it to natively consume/parse/understand output from major testing & static analysis frameworks), and it would be a more compelling alternative. Nobody wants to look at hundreds or thousands of lines of build/test output - the CI tool should summarize the reasons for success or failure. Finally, we're having to run our self-hosted Gitlab on an absurdly large EC2 instance (8 cores, 32GBs). Occasionally we'll have a dozen people converge on a single important PR for review, and before upgrading to our current server this type of event would often bring our instance to its knees. Language choice may be a significant contributor to this -- rewriting major parts of the backend in Go or some JVM language would probably be a good product goal.