I don't have strong opinion against mail-based contributions (I suspect they are perceived as less beginner-friendly by newer contributors who have grown up in the web-interface-based-world, but that's a discussion for another time). The problem here is that a select group of contributors can use a certain contribution procedure (here: Merge Requests), and external contributors have to use a different approach (email or issue-based), or ask permission to use the first-group's approach. In this setting the second approach is *objectively* second-class, and this difference objectively sucks. There are other places that host Gitlab instances without this restriction. The restriction is originally caused by design issues in Gitlab, which ties "sending a Merge Request" with "having a fork on the same server" (which paranoid sysadmins want to forbid to public users as it may create resource-consumption issues). Gitlab is working on making it possible to open a Merge Request by just sending a patch ( https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-by-email-core-only ), and maybe some other git-host server will rise to visibility with a better federation story ( https://sourcehut.org/ ?). (If you are interested in hosting a web platform for git hosting, I'm told that gitea ( https://gitea.io/ ) is much easier to deploy than Gitlab.) On Sat, Apr 4, 2020 at 3:30 PM orbifx wrote: > On 04/04/2020 14:17, Gabriel Scherer wrote: > > 1. gitlab.inria.fr makes it difficult for > non-INRIA people to contribute (they cannot open a pull/merge request). > > Only for those who don't know how to contribute without "opening" a pull > request. Which is otherwise as simple as sending a message with: here is my > repo URL, please pull; or here is my patch attachment. > > > It is a mistake to use it for publicly-distributed software. > > I think not. I find it positively refreshing to see something outwith > Gitlab's dominance. So it's a matter of opinion. > >