I've been using sourcehut more regularly to the point that I have a pretty good sense of things. Unlike similar services — I've found the more I use it, the more I like it.
This might be controversial, but I've found I really like the approach taken to collaboration. Instead of the heavyweight fork and pull-request model of github/gitlab, changes are made almost exclusively via patches and e-mail. While this sounds onerous, there's a neat interactive walk-through at git-send-email.io that explains the process for git nicely.
More than the git e-mail based workflow though, I've found I can use whichever tools I prefer, so long as I can e-mail patches. In my case I get to use Mercurial, cloning repositories via hg-git and sending patches via the patchbomb extension. I already handle mail in emacs, the fact that I can wrangle discussions and patches outside of a web interface is a real bonus.
As far as reviews and discussion entirely over e-mail, I've found the experience pleasant. I am prone to long-winded commit messages but in the case of sourcehut it ends up being the primary means of discussion. It is also nice to get away from some of the modern low-information activity that takes up so much attention and provides so little use, things like "stars" or "emoji reactions" or "followers".
While not a real priority for me in picking a project hosting service, I've enjoyed contributing a few patches to the different sourcehut projects. It might be a result of having a small company actively working on the project or the nascent community interested in the project's alpha but few projects are easier to contribute to. I've been a little shocked at how easy it has been to dive into the different projects, at this point I've fixed:
among a few others. While I've contributed a little to different open source projects in the past, sourcehut is rapidly becoming the most engaging.
One question I'm really interested in: what does sourcehut do to get
contributions so right? There is little information related to
development (nothing like an architecture diagram, let alone
documented internal APIs), there aren't tests, and I haven't
actually installed or run any of the services myself. Instead, I've
found I can take a bug report or question and navigate my way to the
relevant code with nothing more complicated than grep
and with some thought, fix the problem. It is hard to explain the
novelty of this after having spent literal years working on big
professional projects that defy this kind of approach.
If I had to try and pick a reason, I'd guess it is down to the well-defined nature of the project pieces and sensible decision making in the early designs. There is little to none of the sort of architecture overkill so common in big enterprise projects. Instead it reads like each piece was built with a clear purpose in mind, which might be another uncommon feature.
Whatever the reason, I'm happy to use and contribute to sourcehut and you should give it a shot if you're at all interested.