Another way to approach the same question would be to argue that a software forge should not be the monolithic service it currently is. A forge should be made of independent but interoperable services, each with their well defined REST API + ActivityPub:
- A web interface with user management
- A DVCS
- An issue tracker
- A CI
- etc.
Interestingly this may be going in the opposite direction, as exemplified by the CI: they previously were loosely coupled (Travis etc.) and no forge had its own thing. But now that GitLab has its own CI and it is getting popular, it may be an incentive for GItea and others to follow this path. In any case Jenkins, Zuul etc. did not agree on an API that would make it easier for forges to support all of them. And the same can be said of redmine, trac etc.
But if there were established standards for each component of a forge to be independent and nicely plugin each other, I still don’t which feature would not fit in any of them.