My understanding of ActivityPub is not good either but yes, that’s what I have in mind. A Project as in “software project including repository and all other things, issues, merge/pull requests etc.”.
Although an Activity is JSON-LD, the “payload” probably does not need to be JSON-LD. I’m sorry for not using the right vocabulary. Maybe it’s content? Anyway, you understood what I meant despite me being very vague, I’m impressed 
The example you provide is crystal clear, thank you. Assuming all aspects of a software project is represented in a DVCS (not just the code but also issues etc.), the changeset may be the only kind of content that needs to be federated.
The data model to represent an issue or a merge/pull request needs to be decided but it may not be a requirement to implement ActivityPub in fedeproxy. Here is a tentative example to illustrate what I mean:
- On a given project P on GitLab
- I comment on an issue for P on GitLab
- Fedeproxy for GitLab uses the GitLab API to GET all my issues
- Every issue is exported by fedeproxy in a separate file in the repository of the P project on GitLab in the format used by GitLab import/export
- My comment is represented by the diff between the updated issue files and the previous issue files
- Fedeproxy for GitHub receives the activity “apply patch/changeset” from Fedeproxy for GitLab and applies the patch on the issues that are on the P project on GitHub
- For every issue modified by the patch, Fedeproxy for GitHub reads the issues and uses the GitHub API to apply the differences, e.g. for each of my comments verifies it is up to date (creates a new one if it does not already exists, update the message if it existed but does not contain the same thing, removes if it is absent)
Here I assume, for the sake of a draft implementation, that the data model used to represent issues etc. is the GitLab import/export format but it really is a way to not address the issue of a well defined generic format independent of forges rather than advocating the GitLab import/export format is a good format.
What I find appealing in this approach is that the definition of the data model to represent a software project could be 100% decoupled from the definition of the protocol and data model used for federated forges to communicate.
Does that make any sense ? I may have overlooked something that makes this completely impractical, please be blunt 
Or maybe this is just gibberish and does not make sense at all. Again, please be blunt.