Support ActivityPub for GitLab (#11247) · Epics · Epics · GitLab.org · GitLab
gitlab.com
Gitlab/ActivityPub Design Documents by @oelmekki The goal of those documents is...

After 5 years of foot-dragging they finally close the ticket to community protest:

This feature request is being closed as our current focus isn’t in this area.

We appreciate your input and contribution to improving our product. While this feature may have merit, we need to prioritize our efforts elsewhere at this time.

If you’d like to provide additional context about why this feature is important, please feel free to leave a comment on this issue. This will help us better evaluate the feature if we revisit this area in the future.

Thank you for your understanding and continued support in helping us build a better product.

  • rglullis@communick.newsEnglish
    28·
    19 hours ago

    What advantage does a “fediverse” frontend have?

    Github’s dominance comes from the network effects. Everyone’s on github, so if you have your project on a different repo, you won’t get as many visibility. If your project is on gitlab only and someone wants to report a bug, they need to:

    • Find your instance.
    • Create an account.
    • Deal with an unfamiliar interface
    • Create the ticket
    • Hope it gets seen.
    • Potentially forget about it, unless they set up notifications.

    A Federated forge solves all of that.

    • You follow remote projects without having to create an account in the remote instance.
    • You open an issue on the remote forge without having to open in an account in the remote instance, and you do it from your local server.
    • If you have a PR ready, the remote instance gets notified.
    • It makes a lot easier to separate CI/CD from source management.
    • It makes a lot easier to separate source management from issue tracking.
    • etc
    • etc
    • etc