Thanks for sharing more info about this jbk. > - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, peopl

Thanks for sharing more info about this jbk. > - A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice; We actually have an issue open about it - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013. As the issue label suggests, it's definitely a moonshot, but completely achievable in small steps / iterations. > - Custom Fields, in order to leave trac (such a pain, this service is); This one's on our radar as well - https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 https://gitlab.com/gitlab-org/gitlab-ee/issues/1906 > - Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions). Could you rephrase this? I think I'm missing the point. You can update a MR with a regular push. You can also browse through different versions of a MR diff (https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...). A force push "is required" only if your local history doesn't match the remote history.