I love Sourcehut.
I am also 100% certain I have lost contributions from the community because of the lack of a PR-like system. I have been explicitly told as much by potential contributors.
git send-email is a wonderful tool, but I think it's also a relic of its time. People who just want to casually pitch in a change are not going to set it up, no matter how much we want them to.
The one person who HAS contributed this way has had issues with their contribution that I had to spent a long time fixing because I knew interest would waver if I asked them to send it again with whatever weird problem they had resolved.
I'm still continuing to use Sourcehut, but I think it is worth nothing that the rate your community contributes to your project is likely to go down if you do.
@ascclemens I think something that is important to remember is that no one was born knowing how to use pull requests. Anyone who maintains a GitHub project with nontrivial amounts of traffic could tell you that there are many noobs who mess up the PR workflow, too. Everything takes learning and time.
So as people had to learn PRs, so too do people have to learn git send-email. And as the unknowns of git send-email dissuades potential contributors, so too do pull requests.
GitHub is hot shit right now, but it hasn't always been, and shall not always be.
@sir No, but I think one has a higher barrier to entry than the other.
It's also definitely easier for someone to click on a pencil icon and type in their small changes and submit. One of my repos has a YAML file that needs small touch-ups every now and then, and that is the perfect use-case for such a feature.
On my own side, it's easier to merge by clicking a button instead of having to save emails and fumble around with git am.
Is it possible to do without a system like PRs and just use emails/mailing lists? Absolutely. Do projects do so? Of course. Is that workflow ideal or even appropriate for every project? No.
With or without a system like PRs, I'll keep using Sourcehut, but I don't think it's a bad thing to make things easier for new contributors.
@ascclemens on the other hand, once you learn it the email workflow is much faster (and more flexible) in many respects, both for contributing patches and reviewing them.
It takes more to learn, but it's not harder - once you grok it it can often be easier imo.
@sir Don't get me wrong; there are definitely things I like better about the email workflow than PRs. I just know that being forced to use that workflow has dissuaded potential contributors to open-source, regardless of how hard/easy either system is to use or their benefits.
I would love to be able to have people who maybe aren't as competent or experienced contribute, too.
@ascclemens sure, I know what you mean. I'm just pointing out that this is due to github mindshare, which is not really anything we can fix other than by (1) imitating it or (2) being better than it, and I choose (2).
@sir What about (3) make a system both fundamentally better than it (like email) and easier or just as easy as it (unlike email)? I know that's a big ask, but I'm just brainstorming.
@ascclemens I disagree with the premise because I think email gets a ridiculously unfair bad rap
@sir Then what about lowering the barrier to entry?
If I, first-time contributor, want to make a small change to a project and the maintainer of said project tells me I'm gonna need to set up another tool that requires me to look up my email provider's SMTP information, I'm much less interested, especially when the barrier is so low in many other mainstream projects, and especially especially when I'm likely only doing this process for one project and one platform, even though the process itself could be implemented by others. It largely isn't.
Mindshare or not, you can't deny it is certainly *easy* to contribute as a first-time contributor (even first-ever contributor) on GitHub and its associates.
Who's to say getting set up to send emails to a mailing list couldn't be just as easy with the right tools?
@ascclemens this is also true for GitHub, though. The unspoken presupposition here is that you already have a GItHub account. It's actually a much more valid presupposition to assume you have an email address.
@sir There's also the supposition that I am familiar with the CLI or have GUI tools that support this workflow. Also that I am familiar with git.
I'm certain GitHub has invested significant time to make onboarding as easy as they can.
I would say for the vast majority of people, it is easier to set up a new account than it is to set up git send-email.
@ascclemens git.sr.ht also has a web UI for patchset preparation
@ascclemens I do agree that it presumes familiarity with git, but that's by design in this case. Your example use-case of touching up a YAML file is explicitly dis-supported by sourcehut
@sir Which is to my detriment, because that is a very useful workflow in that project. It's also one that would be very easy for even non-devs to do were it not for the barrier to contribution.
@sir Which is nice and I will definitely use, but I was also very confused by it the first time I saw it. I don't think it's particularly clear that you should be clicking that button on your *own* repo.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!