Follow

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.

· · Web · 2 · 0 · 4

@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 @ascclemens I think *part* of the problem here is shitty email clients. Gmail's mass web UI adoption has made email a *terrible* experience for many people and they think the whole system is just broken because of it.

@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.

@ascclemens @sir that I can relate to from personal experience. I'm familiar with git - locally - and yesterday I tried to use git send-email to send someone a patch. I spent 30 minutes trying to figure out how to properly set it up (and indeed even failing to enable debug mode to see what the error was) after which I gave up and just sent the patch file as an email attachment.
Whether that's a failure of the software or just my inadequacy at understanding things - it's probably the second one. But it makes for a point of "this is clearly less intuitive than the alternative" ¯\_(ツ)_/¯

Yes, it did take me a bit to properly figure out PRs on Github. But that started out with "i know i'm doing this incorrectly but it still kinda works so i can learn the rest later", and this was a "nothing works so I need to do something else to get what I want done".
@spiral @ascclemens @sir i skimmed this thread, admittedly, but my take is that the barrier to entry is a result of shit solutions being corporately pushed hard and fast compared to elegant solutions. the people who spend time doing things right are not likely to have as much time to advertise and invest in the widespread use of their solutions

and as such, the elegant solutions dont get used, they dont get supported, they dont get easier to use, they dont get written about, bugs are discovered less often and the bugs that are discovered just blow up in people's faces, leaving the user likely to leave for different solutions entirely. i see this in #bspwm irc a lot, where myself and others run into absolute edge cases and none of us have much developer time to spare learning xorg internals, learning bspwm codebase, learning weird interactions and race conditions between programs

git-send-email is great. i have it set up, i use it to send patches, i hate dealing with gitlab and github (ive had to use both within a recent stretch of time), once it works it works well. i think the "hard part" is the fact that its email. and everyone uses email wrong, and no one understands how unix does email. that isnt the users' fault, thats the fault of the outlooks and thunderbirds that try to bastardise everything and hide the structure of a mail workflow, try to invent their own proprietary configs rather than use standard solutions—sendmail(1) isnt the best thing since sliced bread but it's something that... sends mail, and things that send mail should be using one systemwide binary for sending mail, thats configured to send mail a similar way no matter what program calls it

the "modern" way to do patches is not more intuitive, you just dealt with it more, its more tested, it has more information surrounding it, youve learned to treat everything else as inferior. i wish it wasnt like this, but this just goes to show how far a stubborn person can carry a shitty solution to an ubiquitous problem

@wowaname @sir Right, I think the better solution of sending patchsets via email/mailing lists just doesn't have as much built up around it to make it as easy to start as the solutions pushed by GitHub and co.

@spiral @ascclemens @sir i suggest msmtp for a lightweight mailer, the config file is straightforward, supports multiple accounts if you want such a thing, supports calling out to an external program to fetch your account password

which brings me smoothly into an example of something well-designed *and* well-supported: pass(1). the utility itself is simple (simple enough to be rewritten in something that isnt bash), it can be used in pipelines and scripts, it can be called by other programs entirely, its comprised of simpler tools that you might already have on a workstation, and it has plenty of third-party frontends and plugins and anything you would want. theres a gui for it, in case you want something "like keepass" but with the features pass presents. theres an android app, which i use when im on the go and need access to an account. theres an auto-type script... more software needs to be designed with this sort of extension in mind

@ascclemens @sir I agree the tools could always be better. Maybe someone should write a setup wizard of sorts for send-email.

@sir @ascclemens
> github mindshare
not *quite*. Github feels similar to Discord/Chrome/any other "modern" thing.
i'm not sure if i'm describing this well, but Github feels more "normal" - more like the other things I use.
Thus, I as an average person on the internet today would be more inclined to use Github - even though I *know* that other stuff is substantially better.

So, it is mindshare, but more of modern-internet-as-a-whole mindshare rather than one-specific-service, and that's much more powerful.

@spiral @ascclemens I think I would ascribe this mindshare to the general idea of corporate and/or social media brainwashing, priming users to expect a corporation to stab them in the gut with a big ol' smile on their face

@ascclemens in my experience as a contributor, the exact opposite is true

i recently found a project (https://github.com/Ralim/ts100) with a small bug (the build system uses the gnu getopt extension where it reorders arguments to put options in front)

it's a trivial 2-line patch that i've already written, but i'm not gonna send it upstream because i can't be assed to:
- open up qutebrowser (i normally use w3m, which won't work for github - but does for sourcehut, props to @sir!)
- remember how to log into my github account
- go through 5 different captchas cause i'm using tor
- do 2-step verification via my email cause github probably thinks i'm a bot despite my passing both password and totp challenges
- spend a 5 more minutes fiddling with qutebrowser's config options cause github sucks
- navigate an unfamiliar, extremely laggy, ui (i've submitted 1 pr total, so i don't grok the ui)
- spend the next week havingg to check github to see if anyone's responded to my patch
- repeat this whole mess if anyone wants changes

this whole time, my computer's fan is going berserk because web browsers

if said project had a mailing list, the workflow is:
- git config sendemail.to 'mailing@list.tld'
- git config format.subjectPrefix 'PATCH projectname' # sometimes this step isn't necessary/desirable
- git send-email HEAD~
- i already check my inbox, no need to do anything special to check for feedback
- repeat the send-email command with -v$((counter++)) if anyone wants changes

in one of these workflows, the majority of my time is spent working
in the other, most of my time is spent fighting a web browser tooth and nail

can't speak for anyone else, but i will probably never contribute to anything on github again if i can help it

and in my (albeit limited) experience as a maintainer, i feel similarly - github would require large amounts of fighting with web browsers, email allows me to apply a patch with 11 keystrokes overhead on top of actually reviewing the code, from seeing the email show up in my inbox to the patch applied, pushed, and the contributor thanked

@ecs @sir I think you're not the target for lowering the barrier to entry, though. Experienced developers can use the email workflow and it's much easier. I'm not arguing to remove the email workflow so much as make it easier for people who are new to it or new to code in general.

@ascclemens @sir agreed, i'd love to see https://todo.sr.ht/~sircmpwn/lists.sr.ht/111 closed

also note that i'm not really that experienced of a developer, the first time i touched git send-email was april of this year, and i spent 6w of the time since then without any access to a computer at all (the amount of time i've spent writing code is a lot longer, but up through this april it'd all been for personal projects and therefore doesn't count towards experience as a contributor)

with https://git-send-email.io, the eventual https://git-am.io, the existing web ui for patch submission on sourcehut, and the eventual web ui for code review on sourcehut, i think we've pretty much got an "email but easier to use for newbies" workflow
Sign in to participate in the conversation
Anna's Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!