[dudul]

For example, a lot of people complain about issues on GitHub. GitLab handles those much better, that could be a compelling reason to move, but somehow it doesn't seem to be enough.

Private repo can be useful for early stage of OSS projects.

Agreed though that it still feels too much like a clone of GitHub. The UI for example is way to close to the original.

[stormbrew]

Having used both there's more than enough in either that's bad to justify a switch to the other if you really want to. I personally prefer github's warts to gitlab's. In particular, I find that general site navigation on gitlab is quite tedious and it rarely centres useful information first. But that is very much a qualitative and not a quantitative complaint.

The main thing I find extra useful on gitlab is the ability to mark a MR as a WIP.

[sytse]

Glad you like our WIP function. Do you maybe have any suggestions how we can make navigation better and/or examples of pages where you are missing information?

[cyphar]

The decision of what does and doesn't go in the sidebar is very non-intuitive (sometimes what I want is in the sidebar but sometimes it's in the main page). For example, in groups and user profiles you can find the list of projects in the main body of the page (and it's not visible immediately). Why is it not in the sidebar if you have a sidebar? And then the ordering is also a bit weird -- I don't think many people would consider the order in GitLab to be "in order of importance" or even "regular use". And why can't I see the set of files in the repo when I first open it? This is something I feel GitHub does better -- things are much faster to access and IMO much more intuitive.

[randx]

Thank you for your feedback.

> The decision of what does and doesn't go in the sidebar is very non-intuitive

We try to put top level navigation into sidebar and everything else in the main page. For example navigation to `Projects` is in sidebar however tabs to switch between starred projects or personal projects is in main body.

> For example, in groups and user profiles you can find the list of projects in the main body of the page (and it's not visible immediately). Why is it not in the sidebar if you have a sidebar?

Good example. Agree its still non-intuitive in some places. For you particular example we created an issue to fix - https://gitlab.com/gitlab-org/gitlab-ce/issues/13480.

> And then the ordering is also a bit weird -- I don't think many people would consider the order in GitLab to be "in order of importance" or even "regular use"

Ordering of projects is either by last activity or alphabetically. But in any case there is usually a dropdown in UI to sort by other criteria.

> And why can't I see the set of files in the repo when I first open it?

You can set what to see first at https://gitlab.com/profile/preferences page. We believe README is something people would like to see first we allow users to set different default page based on their preferences.

P.S. Thank you very much for your feedback. It will help us make GitLab UI more intuitive.

[askyruler]

Thank you for your feedback, we aware about these issues and already working on improvements on our side, stay tuned!

[sytse]

Thanks, I've asked our UX engineer to look into this.

[tedmiston]

That would be nice.

In GitLab today, we end up deleting and re-creating merge requests, or waiting until <requester> comments "@<reviewer> ready for merge".

[sytse]

Why do you need to do that? Have you looked at the merge request approvals feature https://about.gitlab.com/2015/07/29/feature-highlight-merge-... (EE/.com only)?

[tedmiston]

It's not about the number of approvers (just one), but more the approver knowing that the submitter is done making revisions. Usually after the first merge request, we do code review then wait for revisions, that's when the tag happens.

Now this would be awesome:

> We’re thinking about more improvements to the Merge Request Approvals, the main improvement being automatic suggestions for reviewers, based on the history of the changed files in the merge request. For instance, if Jane worked a lot on a certain class and you submit a change to that class, Jane gets suggested to approve your merge request.

Today we are using the self-hosted community edition though.

[sytse]

To indicate that the submitter is done making revisions I advise to remove the WIP indicator http://doc.gitlab.com/ce/workflow/wip_merge_requests.html this feature is available in CE and EE.

If we start recommending automatic reviewers based on the blame this would likely be an EE feature.