[mikemcquaid]

Did you contribute to open source in those days? I did a little (KDE patches to mailing lists before I got Subversion access) and: it was _awful_.

You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.

GitHub has made some parts of open source worse (e.g. how easy it is to now open poor issues while ignoring required information compared to Bugzilla) but the contribution side is so much nicer now.

(Bias/context: former GitHub employee, former KDE committer, current Homebrew project leader)

[bombcar]

One thing I’ve noticed is that the people who “live in their email client” (and this applies to Outlook and to using emacs to read email) are very productive if everything is working right. I’ve seen people blow through a number of patches and discussions in their email client faster than I can even get GitHub to load the notifications.

And then there’s a philosophical discussion if burning newbie’s time or discouraging them is worth making the old guard’s time more productive- including discouraging interactions entirely.

(This is why for certain projects you can be entirely useful even if you can’t code; just as an intermediary)

[mikemcquaid]

I live in my email client and only use GitHub's email notifications. When I was working at GitHub and watching Homebrew/homebrew-core: I would regularly get >1000 a day.

I still do not miss the days of doing patch management from my email client :)

[nunez]

When you treat your inbox as a work queue and aim for zero, it's easy to be productive from within your inbox

[keepamovin]

I think the focus of attention that this workflow offers certainly has its advantages. There's likely a variety of factors at play, however!

[Hackbraten]

> This is why for certain projects you can be entirely useful even if you can’t code; just as an intermediary

Argitrage?

[dustfinger]

> You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.

Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I realize that is probably not what you meant though. Besides, when email patching first began, the tooling was in its infancy.

However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better. I never actually use GitHub for merging, even when working on projects hosted in GitHub.

[beepbooptheory]

Spent a long time not even knowing you can resolve merges in github. All I knew was magit and smerge, and assumed people with the fancier editors had something similar.

[mikemcquaid]

> Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge.

I know because I also actually did this.

You still had to do this locally and then turn it into an email and had no real indication whether someone else had seen/tried/reviewed/etc. it

> However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better.

I can totally believe for you: this is the case. For most people, though: it will not be. Feel free to prove me wrong by creating a(nother) project that gets thousands of contributors entirely through email.

(If you're actually Linus Torvalds, though: you win, I'll shut up now)

[ploum]

I had the exact opposite experience.

I’ve never managed to understand how to all those things, always switching between github web UI, github tools, command-line github. Everything was a mess.

Then I left github for sourcehut and managed to read a book about git.

It is still hard but now, everything makes so much sense. When I have a problem, instead of clicking everywhere and blindly copy/pasting results from stackoverflow, I actually think about my problem and what result I want to have.

Yes, the upfront effort is harder. It is like learning Vim or Emacs. It’s hard for the first few days/weeks then you get a lifetime of incredible benefits.

(Bias/context: I’m the author of https://ploum.net/2023-02-22-leaving-github.html )

[gilcot]

You were a github consumer.

You are now a git user.

[keepamovin]

Ha! I love your bias disclaimer -- and you have certainly brought Homebrew out of the darkages (no disparagement to the earlier works); it's noticeably more performant lately. :)

Your skepticism is understandable! GH seeks to bring this collab to all, but back then the skill required to even contribute was a barrier. But in a way that barrier was acceptable and useful.

The people doing it were skilled. The basic level of skill required to even contribute was a lot. I think there’s something to that.

As a 14-year-old it was beyond me, or so I thought, but in truth it probably wasn’t. But yep, you got me; I did not contribute! I was an observer, with a genuine admiration for the simplicity and effectiveness of that method of contribution. How sending something as commonplace as an email can have profound implications when it carries a valuable contrib!

Indeed GH has some joy. Yet while convenient, modern tools might lack the intimacy and individualism of the older, more decentralized methods, which can avoid the immediate public scrutiny that GH may entail.

I suppose you can consider my words an ode to the old ways, and an invitation to consider whether some elements of the past should be reintroduced in today's collaborative environs. This might sound whimsical (and perhaps not entirely accurate), but perhaps the "email method" was even more eco-friendly!

It's not so much I think those things you list are a pain, just the overall "structure of collaboration and social organizing algorithms" (please excuse me; I'm finding this hard to articulate!).

If don't get the vibe of my comment, I totally understand! It's intended to resonate with those who witnessed the evolution of dev practices and share my nostalgia for the early internet of the 90s.

My memories of watching patches flying over those email lists are forever tied up with that whole early internet nostalgia. I loved that stuff. I read zines, and printed off RFCs so I could smuggle them to school and read them, just to “stay in touch” with online, even when we couldn’t connect. :)

[mikemcquaid]

Thanks for the kind words!

> As a 14-year-old it was beyond me, or so I thought, but in truth it probably wasn’t.

Eh, maybe it was, maybe it wasn't! I didn't do any meaningful open source contribution until the tail end of university/college.

> I suppose you can consider my words an ode to the old ways, and an invitation to consider whether some elements of the past should be reintroduced in today's collaborative environs.

A great idea and always worth considering <3

[js2]

I've been contributing to open source projects since the late 90s. I never found the mailing list workflow awful. I also don't find merging/rebasing/resolving conflicts to be much of an issue, and I say this as someone who spent a couple years keeping my company's fork of Chromium rebased on-top of Chromium. Okay, that was a bit of a pain, especially when a new engineer joined Chromium and decided they just had to refactor an entire subsystem.

[pxc]

> You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.

Wait, are people doing this via the GitHub web UI these days? That sounds like a nightmare.

[mikemcquaid]

You can do some of this through the GitHub web UI and sometimes I do that.

I didn't say that, though, so I'm not sure where you're coming from here.

[pxc]

Ah, so it's more about having a git remote to run `git pull` or `git rebase` against than the forge-specific stuff.