I didn’t get the original email in this thread once again, so I think I’d support trying somewhere else to host discussions. Besides archiving those messages into a mailing list, it would be great if the solution provided allowed for email interactivity (e.g., you can reply to the notification of a message and it’s added to the thread appropriately; this is how GitHub notification emails typically work).
> On Oct 10, 2024, at 05:40, 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.
