This post is a follow-up of this previous one about sourcehut.
(Edit: It has been confirmed that an account is not required to use the email features. I've left the rest of the post intact, rather than updating it to reflect this knowledge.)
Today I looked around sourcehut a bit more and learned a few interesting things.
I learned that it's still really fast. It's so fast. I love how fast it loads.
I figured out another part of why I was having trouble orienting myself before: a lack of breadcrumbs to keep track of where I've come from. If you're looking at an issue on GitHub, you can see the issue you're in, and then at the top of the page, you can find your way back to the issues tab, the repo page, and the repo owner's page. On sourcehut it gets a bit trickier. Often there aren't as many handy visual indicators to keep track of where you've come from and guide you in stepping back to where you were. Sometimes links take you to a completely different part of the site, with no way to return apart from the browser's back button.
Now that I'm a little more oriented though, I think it could be a good platform. I'm actually considering moving most of my development there. I'd definitely have to write some documentation showing people how they can submit issues and patchsets since it's not the most obvious thing.
In sourcehut, issues are called todos, and they look like this. This is actually really nice UI. It's easy to submit an issue report: if you're logged in you can type a subject and body into the web UI, but whether you have an account or not (at least, I don't think you need an account?) you can also choose to send a plaintext email with your report. I think this is actually really convenient.
The pattern of things being accomplished with email continues with merge requests, or whatever you want to call them. sourcehut calls them patchsets. There is a web UI, but you're encouraged to use git send-email to submit patches. This is a bit more of a learning process than some people are used to, but I think it could work well if everyone involved knows what they're doing.
I do sort of know what I'm doing thanks to that extremely well designed web tutorial (seriously, thanks for that) and I managed to create this real patchset with some changes to the documentation, inspired by this discussion on the mailing lists.
Fortunately, if you don't know how to use git send-email, sourcehut does have a web UI that seems pretty hot. You send your changes to your sourcehut account, and sourcehut then allows you to select which changes you want to be in the patchset, and then it lets you email the patchset to somebody for review. I think this is a pretty good process, but I'd of course like to try it in practice. Maybe I can get Preston from FreeTube to sign up... U+1F914
I really appreciate that these features only require sending an email, and not an account on the website, to use. (At least I think that's that case.) I think this makes development much more accessible to everyone, and skips the main annoyance with hosted git alternatives, which is having to spend 10 minutes signing up for an account on the hundredth alternate site which you'll probably never use again. My only concern is that since the web UI is of course much more convenient for people to use, that in the future when accounts become paid, I hope that features like patchset selection and issue reporting will still be possible on the web UI, since requiring people to pay money to be able to easily send changes to some other open source project would be silly.
I'll have to try out sourcehut with some more people while accounts are not paid, but it's looking promising.
To the people saying everything will be solved by federated git, I don't think federated git will ever happen. Allowing people to use their regular email address instead of requiring sign up on yet another website just works better, since you already have an email address, and email is already federated.
— Cadence
