[Meta] Move to a forking workflow for GitLab CE development

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

This is a meta issue to track the problems blocking us from moving to a forking workflow in the GitLab CE project. We shouldn't be working in a pristine glass castle that's not representative of the experience GitLab.com users are having.

There are a few reasons we want to do this:

• Fewer branches in gitlab-org/gitlab-ce
• More representative of what users are struggling with, leading us to fix problems with the product that only crop-up when we're using it with a forking workflow like this.
• We'll be able to better handle contributions to the open source project since team members and contributors will both use a similar workflow.

Potential Problems:

• Builds may be slower (something we should fix)
• We can't restart builds for other people's projects if they aren't shared with the GitLab.org group
• Maybe harder to test a branch locally?
• You end up with a bunch of extra branches that never get deleted and are too annoying to delete
• Not as easy to have more than one person work on a branch, the fork owner will have to give permissions to their fellow team member(s) (bug or feature?)
• It’s hard to get to the fork project (for me it doesn’t show up in the Project selector unless I explicitly search for it), this may be because I use the Activity Feed as my default view
• Can’t track progress of a feature branch if an MR hasn’t been opened (this wouldn’t scale anyway once we have more engineers, maybe a feature?)
• The GDK hasn’t really been tested for this situation, except by myself and Jacob when he originally implemented the upstream workflow
• Change is scary!

cc: @DouweM @rspeicher