Docs feedback: need recommended workflow for not-on-team

There are two merge request workflows listed in the documentation https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-workflows, both involving a developer working on a team project.

Some of us are migrating from GitHub, for whatever reasons, and bringing over open source projects, for which neither workflow is applicable. A typical OSS project is not written by a team, but rather by just one project author. Other contributors are not members of the project and have no write access to it. These limitations make the workflows documented above cumbersome.

Because I can not write to the project to which I am contributing, other than to create an issue, I have to fork and work on that. When I create a merge request to commit my changes, the MR appears only in the original project and is not linked to my account in any way. When I want to view the MR, I have to navigate to the original project and look at it there. I do get email notifications and I am able to manually add it to my todo list, but it does not appear in the merge requests view from the dashboard, since I am not and can not be assigned to the MR. When the MR is merged, there is no way to delete the merged branch automatically; I have to go and delete my fork deep in its project settings. Then there are the usual difficulties of keeping the fork updated, while I'm working on the changes; a non-trivial task that I have to lookup instructions for every time it's needed.

There are all these little inconveniences due to the recommended workflow being unavailable in this situation and to some of the GitLab features not working as intended. On GitHub, the work-on-the-fork is the default way of doing things, so it is much more streamlined. Pull requests are listed on my account and so are the notifications on it. I also get one-click ways to rebase the fork and to delete it once the PR is merged.

On GitLab, on the other hand, I have not been able to find a suitable tutorial on the recommended way to work as an not-on-the-team developer. Perhaps the GitLab docs could suggest something appropriate?