Comment

Comment on is it just me or GitHub is turning into some sort of LinkedIn

Kissaki@feddit.de ⁨11⁩ ⁨months⁩ ago

I’d rather not have to register on every individuals instance for every project, for big reporting, discussion, or simple changes.

On github it’s easy for me to contribute and communicate. On other platforms, not.

source

Sort:hotnew top

exu@feditown.com ⁨11⁩ ⁨months⁩ ago
There’s work to have instances federate, similar to how Mastodon or Lemmy work. And the admin could also enable Oauth2 login with GitHub and GitLab for easier access.

source
- philm@programming.dev ⁨11⁩ ⁨months⁩ ago
  For reference, I think you’re referring to this: forgefed.org
  
  source
shagie@programming.dev ⁨11⁩ ⁨months⁩ ago
You could set up a mailing list for the project and pass around email patches.

git send-email and git am are core parts of the functionality.

While github.com/torvalds/linux does exist, the workflow for the various modules is described in github.com/torvalds/linux/blob/…/MAINTAINERS and the PR bot that shows up on pull requests in the repo: github.com/torvalds/linux/pull/782

… and email is a federated protocol that is resistant to censorship that is associated with having a single server hosting the content.

source
- Kissaki@feddit.de ⁨11⁩ ⁨months⁩ ago
  Did you reply to the wrong comment?
  
  I was talking as a user or contributor.
  
  source
  - shagie@programming.dev ⁨11⁩ ⁨months⁩ ago
    If the open source project is managed with local repos and patches are sent via email for consideration and integration, one doesn’t need to register remotes for each individual’s instance of the repo for each project.
    
    With a bit of adjustment to the “how this works” for the workflow (rather than relying upon GitHub or Gitlab or any other centralized repo), git shines as a distributed version control system that is enabled with git send-email and git am.
    
    The repo can be published to any of the hosting sites, but the workflow for changes, bug reporting, and discussion happens over email rather than via the implementation specific aspects of one hosting site or another.
    
    There won’t be the issue of “this repo got taken down from {host} because it was owned by someone logging in from a sanctioned country.”
    
    Yes, centralized hosting solutions make it easy to do these things… but the federated and distributed way to avoid them is hosting independence by managing the project through email.
    
    source