[gitlabuser]

I'm also getting frustrated from Gitlab. My company has been on gitlab EE for over a year, and while they have pushed out features quite quickly, their UX is still way behind github. I think they don't have a laser focus on the user and spread themselves thin. There are basic user flows that lack the polish; for example merge requests actually are a pain to edit. If you click the edit button, it does a full page load (instead of doing it using ajax) and the page takes a few seconds to load. So trivial things like fixing the title because of a typo or changing the assignee are actually quite painful. They've hacked a solution by allowing you to some changes through back slash commands but it's still a hack that doesn't address the core problem. Even things like finding all the merge requests where you are listed as an approver is a pain. We have an internal Q&A site and the running joke is that every new hire during onboarding asks the same question "How do I find all open merge requests where I'm the approver" and the answer is always "we don't know". If took them a while to even notify you when your merge request was approved (so you could merge it). Just basic, basic UX is completely unaddressed while they roll out big features like burn down charts, todos, boards. Keep is simple stupid.

It's sad because I want gitlab to win (I believe in both their remote and open source approach) but Github's UX is so much better. We just acquired a company that uses Github so now we have a few engineers using both tools side by side and they all prefer Github's UX at this point so we might switch.

[lloeki]

> their UX is still way behind github. I think they don't have a laser focus on the user and spread themselves thin. There are basic user flows that lack the polish

Using both regularly, the whole create issue 1234-> autocreate branch+MR -> git fetch+checkout 1234<TAB> -> code -> git push -> review -> resolve discussions+open issues for unresolved -> merge+autoclose+autoremove branch -> git fetch --prune flow is downright awesome† and really acted as a catalyst. GitHub just feels so antiquated and cranky compared to that so depending on what you're looking for this frustration can definitely go both ways.

† and it'll be even more awesome when we will soon enable per-branch review deployments which get auto-destroyed on branch removal, followed by auto-deploy of master in staging + manual in production, all neatly tracked in the environments tab.

[mbaha]

I don't think Github are looking to implement the whole CI process.

They want to host code and integrate neatly with other CI providers.

I think that makes much more sense (why abandon Travis or Heroku for the sake of having "one" platform to rule them all... ?)

[mydigitalself]

Hi there, thanks for the feedback.

Our UX team has grown considerably recently and this is a big area of focus for us.

In addition to small UX improvements all over the product, we are also doing a massive overhaul to the overall navigation of GitLab starting in 9.4. This work will continue behind a feature toggle for a couple of releases. You can see the work here (https://gitlab.com/gitlab-org/gitlab-ce/issues/32794) and, as always we'd love to hear your thoughts on it, free to ping me directly in that issue on @mydigitalself to discuss.

[svesselov]

> merge requests actually are a pain to edit.

Thank you for the feedback. We are actively working on making the merge request flow faster and easier to use. We have set up a round of user research to get insight into what works, doesn't work, and how we can make it better. Questions like: >"How do I find all open merge requests where I'm the approver" should be easy to answer and we are working on making that happen.

I would love to have your insights as part of our ongoing research. If you are interested, you can sign up to participate here:

https://about.gitlab.com/researchpanel/

[victorwu]

Thanks for the feedback regarding editing merge requests. In this release, we brought inline editing to issues. (So you don't have to do a full page load, like you mentioned.) So we will definitely bring this concept to merge requests at a later release.

Regarding searching by approvers, we definitely recognize it's a common flow. And we've documented it in an issue. https://gitlab.com/gitlab-org/gitlab-ee/issues/1951. We hope to work on it soon.

[victorwu]

Inline editing is important design direction we are heading toward. The benefit is that you don't have to reload the entire page. And of course you can do single tasks, like updating labels / milestones / titles / descriptions all independently and separately, providing a more web-app-like experience, instead of a website experience. Ultimately, it's more usable and efficient.

In particular for the issue / merge request description areas, we want to get to a more collaborative design in the future when you can see other users making changes in super near-real-time, almost like Google docs. Currently, our issue descriptions already are updated in real-time, but it takes a few seconds for you to see updates. So we are working hard in this direction and we appreciate the validation that inline editing makes sense.

[user5994461]

> (I believe in both their remote and open source approach)

GitHub is also remote.