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.
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).
and I guess it is possible for some people to stay on top of that
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.
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).
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.
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.