Surely a few of us have found a project missing something we wanted it to have and considered forking it.
For some reason or another that idea just fell flat because we either didn't want to "compete" with the official project , didn't want to go through the effort of maintaining yet another project, or myriad other reasons.
In my case, the things I'd like are mostly small and unimportant (or not worth the hassle) to the official maintainers. Other times the project has intermittent updates that I'll miss downstream. And sometime I don't want to stir up confusion by providing another package with a minor change that doesn't get updated.
Fork to gitlab
Gitlab provides push and pull mirroring, which means updates upstream can be pulled into the fork, and updates on the fork can be pushed somewhere else. What gitlab doesn't do however is handle merge conflicts. So, if you forked a project and started making changes to the master branch, pulls from upstream are either overwritten or just fail. However, that's the only problem and luckily it can be solved fairly easily.
Handle merging ourselves in order to detect errors and handle them manually. The manual treatment is in the form of a merge request which means human intervention.
Once the merge request is created a wrapper script can send a notification via twitter, email, Signal, carrier pigeon, or whatever medium deemed necessary.
f2g has a very simple flow:
Fork a project with the script. It will setup pull mirroring.
Manually create a branch and make the changes you like.
Let gitlab mirror upstream into the fork
f2g syncto attempt merging the source branch (most likely
master) into the fork branch. This can be done as a cron job (that's how I do it), manually or however you want.
It was beyond my laziness to find the gitlab issue tracker, create an issue, wait for it to be implemented at someone's leisure, or for me to relearn Ruby and implement the feature. Ah... another reason I create forks...