this post was submitted on 17 Aug 2025
393 points (99.5% liked)
Open Source
40337 readers
254 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Mailing list https://git.ffmpeg.org/ffmpeg.git
I'm probably gonna sound like a noob now, but how does one even properly handle issue tracking, working like that?
I'm not an ffmpeg maintainer, but it's actually not as hard as you think. You know how when you get an email it shows up in your list of emails? That's your list of issues.
You know how when you get a reply to an email, all email clients that aren't the most absolutely basic will put the original emails and its replies into a thread together? That's the conversation about an issue, in context, with threading.
You know how emails can have attachments? That's attachments. You can put screenshots in there, or patches, lots of stuff.
Now you may be wondering, that sounds like a lot of emails. That's true! But most people who live the mailing list life have filters and stuff setup to expect a lot of unsolicited emails. Like there are headers in the emails from mailing lists that tell you which list it was from, so it's really trivial to have a thing that puts all mail from this list into a folder or something and then not notify on emails in that folder. So, like an issue page, you can check it periodically, maybe mark certain ones as notification worthy, and ignore the rest.
The main upside to this is that the theoretical barrier to entry is relatively low, because every human who has touched a computer basically has an email. And you can have ultimate control of your experience because really it's all about what features your mail client has. And even if the mailing list server goes down you won't get any new emails, but you already have all the emails you've received before, so it's distributed! And you can still send replies while it's down, and they'll just spool until things come back up. Magic!
The main downside is that the practical barrier to entry is relatively high because people aren't used to joining mailing lists and aren't setup for it, and so it ironically feels like a much bigger deal, if you're any "normal" kind of email user, than creating a new username and password account. So for casual users, it's kind of a nightmare.
Also, because mailing lists are usually public, it's really easy to make a web frontend that contains the archive for non-subscribers and search engines and stuff, but while these could look like anything, in practice they look like ass, because mailing list people don't really care about what web stuff looks like a lot of the time. Which makes sense, they're not looking at the web frontend, they're ssh'd into a jump box using mutt through screen, or some set of emacs plugins 😛
Awesome and detailed explanation, thanks. I figured they'd be juggling a lot of mails, and I guess it is possible for some people to stay on top of that and keep it all organized with a good mail client, but still... I would get lost so quickly.
Thanks again!
Yeah, but organized into as many threads as there are issues/PRs, so it's exactly as daunting as the same list as viewed on GitHub/project/issues (because it is exactly the same content).
It's the crux of being a maintainer, it's your job "to stay on top of that", with, on larger projects, ad-hoc tooling and automation being the only way. Email is infinitely more flexible than the one-size-fits-all take by GitHub on that.
Surely, dedicated tools for managing/tracking issues give you better tools for triaging, filtering, planning and such, compared to a mail client...
You're almost not wrong, but I think what you're discounting is how much power a lot of email clients have. Especially the "old" ones. People were hanging out on mailing lists before the web existed, so there's a lot of tooling in there around filtering, tagging, flagging, etc.
Remember flags? That feature of mail clients that's like "why would I use this?", or smart folders, that feature of mail clients that allows you to use a pre-written and saved search filter and browse it like a folder? These were written at a time when the email client was the social communication interface.
And if something in there should be insufficient, you can always write a script or something that interfaces with email as an API of sorts.
While it's true that a dedicated tool could be good, in a sense the email client is a dedicated tool for this, and importantly it's one that I control on the client side to do anything I need it to, regardless of whether or not anyone else on earth needs it to do this. My email client serves me.
Quick addendum before people come for me: I claimed email was "the" social communication tool. Yeah yeah IRC gets a say here, but we can all agree it's different. And then also newsgroups, but I don't want to open that can of worms. Just know that you've been named.
Why would you think so? Can you give examples of specific tools that wouldn't be available to mail clients? On the other hand, there are many things available on most email clients which are missing on GitHub, like tagging automation from custom and flexible rules, Turing-complete filtering, instant searching, saved searches, managing the lifecycle of issues, linking with the VCS etc. all in context and in one place.
How people generally go about re-implementing those on GitHub is with bots, and you are left at the mercy of what the bot can do/its admin wants you to do, and each project is its own silo and possibly breaks your workflow.
I'm fine with GitHub because these days I'm mostly a casual contributor, but there's a lost appreciation for the sheer power and universality of email-based workflows. That the largest projects (including the Linux kernel) run on that should speak for itself.