> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
On a technical level that seems an impossible distinction to make. Someone wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.
Yet, there is still differences. Allowing only "fork" is a good and easy thing.
Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
I'd think it's pretty easy to have a policy that says "only VLC forks or VLC-related projects". What if someone wants to pull out part of VLC into its own library?
On your own instance, disallow creation or restrict of further projects. Ask people to use the 'Import any repo by URL' feature in GitLab on their own instance / GitLab.com.
We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].
It would still send a signal of "please don't do that" - and could be "enforced" with some change/diff tracking in a cron job (all files changed removed - prompt someone to have a look, or just freeze access for a week/month then schedule for deletion).
On a technical level that seems an impossible distinction to make. Someone wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.