💾 Archived View for idiomdrottning.org › forgefed captured on 2024-05-10 at 11:30:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
One way GitHub could make itself a lot better and less hated-by-me would be if they set up a way for people who don’t have accounts on there to contribute with git send-email and/or git request-pull (the latter obviously requires some place to host repos). They could translate those contributions in the fancy-schmancy (probably better known as super confusing) “pull request” format and interface GitHub-using devs love so much. Their gh cli thing is fun and all but that still requires an account, which is the biggest reason for my hatred of them.
I was looking enviously at sourcehut and being intimidated by trying to install it (since the docs are all like “warning warning warning this project is a super scale project that stretches many servers”) but the other day my envy disappeared when I realized that my current setup—plain cloneable repos + a mailing list—is, from a non-maintainer contributor’s perspective, not much different from sourcehut. A way to browse the repos without cloning them is the only thing missing, and I’m on that. (I just need spoons. Looking at softserve and cgit as options. But I kinda also don't wanna do anything and just chill.)
Even if GitHub were made open source under the AGPL, if it kept the same “you need an account to contribute” problem we’d still be in trouble. That’s also the problem with a lot of other forges like Gitea.
Having a forge set up to provide a fancy schmancy UI around send-email (like sourcehut) and/or pull-request would solve everything. No need for ForgeFed when we’ve already got email.
There are three use-case a good forge needs to support.
1. The maintainer, who has chosen a particular forge because they presumably like its UX and how it arranges changes and issues and change proposals. This is de jure well supported by all forges since it’s self-selecting. You wouldn’t use a forge if you thought the experience sucked. In practice we have path dependency externalities like “stars” and contributor difficulties (as outlined in 2 and 3 below), hence why I qualified “a good forge” above.
2. The steady & serious contributor who has their own favorite forge but where the issues and changes are federated.
3. The drive-by contributor. Your horde of typo-fixers. They maybe don’t need to import all the issues and change requests (patch stacks or pull requests), they just want to be able to send a quick fix and move on.
Email can do that second, middle thing, is what I’m saying; implementing smtp directly into the forge if need be, if people can’t be asked to use non-web apps.
I sent a patch and opened an issue on Emacs’ debbugs installation the other day, got convinced the patch was unnecessary because you can already hit M-n to do what I wanted, and closed the issue, all from the cozy comforts of my own command line. A little fiddly but I didn’t need to register an account so already we have infinity less fiddliness than some of the other popular forges out there. And if I wanted to “graduate” to level two, a steady and serious contributor, I still could without making an account. I could set up email plugins etc etc. Already have one for notmuch to extract sent patches.
(Is any of this easy to learn / use? No. I vaguely remember trying to figure out the Debian BTS twenty years ago and giving up. But what I’m saying is that all that CLI goodness can be the backend for the federated forges to build on and slather UI and wizards on. No need to reinvent a new JSON / ActivityPub based protocol when we have good old spray-on usability.)
The diminishing inconveniences of contributing to GitHub projects
#61718 - [PATCH] Fill minibuffer when dired renaming one file - GNU bug report logs