You can do it but at GitLab we advise against it if you can avoid it. Many things become harder, for example it is more work to to link merge requests to issues and you can't push a commit to help a person without them giving you access first.
If you are using the Integration-Manager workflow (which GitLab doesn't support as well as Bitbucket or GitHub), all the members of a team have read access to all the repositories and forks in the team namespace. That means the owner of a developer branch fork can always read the repo of another contributor and pull the changes.
Please let me know what you think we should improve to support that workflow better.
Anyway, I think my examples are still valid, it is harder to mention issues and you can't push (write) commits on forks since your have read permissions.
The main assumption in the Integration-Manager workflow is that code from repositories of other users is always pulled by the owner of the current repository as and when appropriate.
So if dev1 and dev2 are working on the same feature in 2 different forks of the main repository, dev1 has to pull commits from dev2 that are needed in his/her fork and dev2 has to do the same in his/her fork. Once the feature is complete, the merge request is created from one of the 2 forks.
Yes it is harder to mention issues, but that can be done in the message of the merge commit. Since forks are essentially equivalent to branches in this workflow, I usually don't mind referring to issues in the individual commits itself which would link to the correct issue on getting merged to the main repository.
We do this with our team's projects hosted on Bitbucket, ymmv.
