I cannot express an opinion without knowing what the replacement is and having experience with it. Mailing lists have one great feature - they are easy to search. For that reason anything we choose should be just as easy or better. We must also stick to a single medium for formal communication for the same reason.
We do have the ability to experiment with whatever we want but votes need to continue here until we have ASF approval. Ralph > On Oct 10, 2024, at 3:41 AM, Christian Grobmeier <grobme...@apache.org> wrote: > > Hi > > I am generally open to such experiments. I would start with the easiest > parts, such as users@, and see where it goes. > > I would advise against mirroring it to users@ behind the scenes, as it may > cause privacy problems (we need user consensus to mirror it). When a user > uses GitHub, they know what to expect. > > As for Discourse, many use that now, but I find it very overwhelming and > stressful. I prefer the clean Github discussions approach. > > I haven't checked against ASF policies but feel positive about this move for > the arguments you have given > > Kind regards > Christian > > > >> On Thu, Oct 10, 2024, at 10:58, Volkan Yazıcı wrote: >> *Abstract:* Modern email system security measures make it practically >> impossible for mailing lists to work – many subscribers don't get all >> emails. This not only hinders communication, but blocks an inclusive >> one. *Shall >> we, as Logging Services, experiment with alternatives?* >> >> *Motivation #1: mailing lists technically don't work* >> >> Several widely-used email providers (GMail, Yahoo, iCloud, etc.) have in >> the last couple of years enabled new measures (DMARC, SPF, DKIM, etc.) to >> verify the authenticity of emails. In short, these measures enrich email >> content with checksums and signatures capturing its authenticity. When a >> mailing list system (e.g., ezmlm, mailman) receives such an email, it >> performs several changes on its content (adds information about the mailing >> list, etc.), and delivers it to all subscribers. When the mail server of a >> subscriber receives such tampered mail, and if that mail server happens to >> have earlier shared authenticity checks enabled, it discards the email, or >> at best, marks it as spam. >> >> Ralph, Matt, Piotr stated many times that they don't receive all emails. >> Ralph actually stated many ASF mailing list emails end up in his spam >> box >> <https://the-asf.slack.com/archives/CBX4TSBQ8/p1728032221080189?thread_ts=1727958807.348019&cid=CBX4TSBQ8>. >> Recently we witnessed even Brian Proffitt (VP, Marketing & Publicity) >> suffer >> from the same problem >> <https://lists.apache.org/thread/yfmrpjslcbo5jmsqqpvtok1o6lht11rb>. >> INFRA >> is crawling with related tickets: INFRA-24574 >> <https://issues.apache.org/jira/browse/INFRA-24574>, INFRA-24790 >> <https://issues.apache.org/jira/browse/INFRA-24790>, INFRA-24845 >> <https://issues.apache.org/jira/browse/INFRA-24845>, INFRA-24850 >> <https://issues.apache.org/jira/browse/INFRA-24850>, INFRA-24872 >> <https://issues.apache.org/jira/browse/INFRA-24872>, INFRA-25947 >> <https://issues.apache.org/jira/browse/INFRA-25947>, INFRA-26171 >> <https://issues.apache.org/jira/browse/INFRA-26171> – there are dozens >> more. >> >> This technical difficulty is not only known to us. AFAIK, this is one of >> the main reasons PSF (Python Software Foundation) decided to switch from >> mailing lists to Discourse. Mailman documents several DMARC mitigations >> <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html>, >> but I think these are workarounds/hacks rather than well-established >> solutions. >> >> *Motivation #2: ezmlm is dead* >> >> ezmlm, the mailing list software ASF uses, is dead – it is neither >> developed, nor maintained anymore. (Last official release was in 1997, >> there >> is the `ezmlm-idx` add-on, which later on became a successor >> <https://untroubled.org/ezmlm/faq/What-is-the-difference-between-ezmlm-and-ezmlm_002didx_003f.html>, >> which last produced a release in 2014, and so on. Long, dead story.) >> INFRA >> maintains a very big, sophisticated set of Perl rules for running ASF >> ezmlm >> instances. If you look closely at the INFRA tickets I cited above, some >> suggest INFRA to fork ezmlm and fix some long standing bugs, etc. We can >> discuss the possibility of migrating from ezmlm to mailman (yet another >> mailing list software, but one that is still maintained), whether such a >> migration should be practiced ASF-wide or only for Logging Services, >> etc. >> But eventually, we will still be using a mailing list, and as I tried to >> explain above, IMO, they just don't work good. >> >> *Proposal #1: Experimenting with GitHub Discussions* >> >> GitHub is our development bread and butter. We use its tickets, PRs, >> reviews, discussions, CI, security & code quality checks, etc. It works >> perfectly and components are integrated well, i.e., you can link issues, >> comments, PRs, CI runs, etc. Users like it too – we all witnessed the >> sudden increase in user interactions after migrating to GitHub Issues >> and >> Discussions. We can configure sections & categories in Discussions >> <https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-categories-for-discussions> >> to make it serve as our main communication medium. It also provides mail >> notifications and the possibility to respond to them for those who still >> prefer their email client over a browser. >> >> In short, we can quickly configure Discussions, update our support policy >> page, and start experimenting with it. >> >> One can raise the argument that what if Discussions disappear? We can >> mirror communication there to a mailing list to be on the safe side. Yet, >> we need to evaluate the necessity of this. >> >> *Proposal #2: Experimenting with Discourse* >> >> We can get a VM from INFRA and manage our Discourse instance. Though, >> AFAIC, this will result in a "GitHub Discussions"-like setup with all the >> integration goodies missing and added server maintenance burden. >> >> *F.A.Q.* >> >> *What if GitHub Discussions disappear?* >> >> In such a case, I presume they will allow us to download the existing >> archives. In the worst case, we can decide to mirror the communication >> there to a mailing list. Yet, we need to evaluate the necessity of this. In >> particular, how big of a problem is this at the experimentation stage? >> >> *How will private communication work with GitHub Discussions?* >> >> We can create private repositories for internal/private communication. >> For >> users/researchers wanting to submit & discuss security issues, they can >> get >> in touch with us (either via email to `security@logging` or some other >> ASF/INFRA mailing list), we can grant them permissions to collaborate >> privately on a repository security advisory >> <https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories> >> . >> >> *Don't the ASF legals require mailing lists?* >> >> I am aware that several ASF policies require mailing list communication, >> e.g., for voting and such. I first want to establish a consensus among us, >> and then pitch to the board for exemption as a pilot. >> >> *Shouldn't this proposal be practiced ASF-wide?* >> >> This will be a very (very very very, actually!) daunting route to pursue. >> I'd rather start small, solve our problem first (if we can), and then think >> about widening the scope.
