mailing-lists.org 3.6 KB
The Problem
Many software projects communicate and develop software via public email lists (also known as mailing lists) instead of using web interfaces like Github. This usually confuses young developers, because they generally prefer a web based workflow (like Github), which is often seen as easier to use. However, more seasoned developers find web workflows restricting. Sites like "Github.com" force developers to use one, and only one development workflow. This can be annoying for developers, who want to help several programming projects, because they have to learn how to use a "Github" workflow with a "FIXME add another site here". That is why seasoned software developers generally prefer email lists; email lists lets developers cultivate their editing workflow.
Furthermore, web based workflows force the separation of software projects in different and sometimes distant compartments, which may hamper communication between software projects from different web sites. For example, suppose the authors of a popular JavaScript library, which is hosted on Github, plan to improve their JavaScript library by make a breaking API change. Usually the authors, will gather feedback from other projects that depend on their library, before making this API change. The JavaScript authors begin to notify all such projects on Github, "FIXME add another site", "etc", which may mean logging into many different web workflows, and filing a bug report with each project. Conversely, when glibc planned on making a significant and breaking API change, they just sent an email to the glibc mailing list, and CC-ed all the other relevant mailing lists.
Now that the reader has a beginning introduction to the benefits of an email software developmental workflow, the reader is also probably interested in using such work flows. To get started, consider that software developers' send and receive hundreds of emails per day, and developers needed a reliable method to sort through these numerous emails. The answer lies in the email header "List-Id". When a computer user sends an email to a mailing list, a program (usually GNU Mailman), on the remote server, adds the email header "List-Id". Then the program forwards the email to the other users that are subscribed to the email list. Developers can then filter email via the "List-Id" header, because its content does not change; its consistency is guaranteed.
Please consider teaching your email provider (dismail.de, or riseup.net, etc), to filter your mailing list emails into the appropriate folder, because your email provider can do this sort of filtering much faster and more continuously than your email client.
However, this is only part of the solution, because mailing list users also ought to specify where followup emails should go. You can use the "Mail-Follow-up-To" for this. Mail-Followup-to lets the poster alert the rest of the mailing lists that follow up emails should go to just the mailing list or to the mailing list and the poster. 1
Footnotes
the "Mail Followup To." Follow ups to mailing list posts that are sent directly to the poster, do not contain this header. Only emails that are sent directly to the mailing list contain the header "List-Id", because the only mailing list program (usually GNU Mailman) has the ability to add the "List-Id" header.
- Regretably, the "List-Id", email header cannot do the job of